Debugging Python & C++ together

[ypvs421]

Can anyone advise on whether they've succesfully set up a debugging environment that allows for stepping through the python elements & then seamlessly stepping into & out of the underlying C++ as needed? Is there a straightforward way to accomplish this? Conan seems to configure a RELEASE project for Visual Studio that compiles. But requesting a DEBUG build project generation... seems it gens an assortment of issues.

[salvador-castro]

The root cause is almost certainly a Release/Debug Python ABI mismatch, not a Conan bug per se. Official python.org builds on Windows ship Release-only binaries. When you generate a Debug VS project, CMake/pybind11 try to link against the debug Python libs (python3x_d.lib) and load _d.pyd extension modules — which most installations don't have. This is a known pybind11 pitfall (see pybind/pybind11#3403): find_package(Python) on a Debug config picks up the release interpreter but debug libraries, producing unresolved symbols / linker errors.

Two practical paths:

1. Don't use a true Debug build for the C++ side. Use RelWithDebInfo (or Release + /Zi /Od if you want optimizations fully off) instead. This still links against the normal Release Python runtime everyone has installed, while giving you full PDB symbols and stepping. In Visual Studio, on the Python project go to Properties → Debug tab → check "Enable native code debugging" — that's what lets you step from Python directly into the C++ frame without a separate attach step.

2. If you genuinely need a Debug Python ABI (debug CRT, debug allocator checks, etc.), you need a debug build of CPython itself — python3x_d.dll/.lib and the _d.pyd standard library extensions. The official Windows installer has a "Download debug binaries" option under the advanced installer options; alternatively build CPython from source or use a package manager feature that ships debug binaries (e.g. vcpkg's python3 debug feature, with the caveat from [python3] Install debug versions of .pyd files microsoft/vcpkg#28130 that debug .pyd files for native modules aren't always bundled). You'll also need your Conan profile's compiler.runtime set to MDd consistently across all dependencies, or you'll get binary-compatibility build failures on top of the ABI issue.

In practice, option 1 (RelWithDebInfo) is what most projects mixing pybind11/Boost.Python with VS end up using for day-to-day mixed-mode debugging — it avoids the whole debug-CPython dependency chain while still letting you set breakpoints and step seamlessly between Python and C++.

[ypvs421]

Very much appreciate that detailed response. I'll see where these suggestions take me! I do seem to be failing victim to what you're describing in the beginning. If option 1 gets me mixed modeing I'll be set!! Thanks so much

[ypvs421]

@salvador-castro - Can I bug you for the specific simple steps to get on Path 1? Here are the steps I'm employing...

• Getting conan to spit out a .sln doesn't build on windows
• The only way it will build is if a full build is done via conan first
• So, after having a building release version in VS... I switch the config to RelWithDebInfo... This will NOT build, many errors.
• Complains of many dependencies on external libs & these libs (if provided manually) are missmatched & will not compile. All of the required libs exist in conan cache. But they're the wrong type (release). They won't work. Many Linker errors. Any ideas on how to get around this?

A bug in conan script...

• When I select a debug build param the cmake cmd still executes as release (this is an error in the windows conan script)

Questions:

• Is it easier to build a multi-mode debugging environment using linux? We require lots of other Bsk integrations that are running on Windows so this is ideal. But if mixed mode comes together much easier on Linux... I mean anything would be nice. Any thoughts? How do the Bsk developers do mixed mode?

[ypvs421]

Update here: After many VS manual configuration changes I did finally get a RelWithDebInfo finally to build on Windows using only the existing conan cached artifacts. Did not need to download or build any other C++ or Python packages. NOTE: I was succesful getting RelWithDebInfo to build by starting w/ a succesful "Release" build. Most changes were accomplished adding missing include & lib paths to specific projects & implementing a global Directory.Build.props sheet. Very happy to be making some progress...

[ypvs421]

Another update:

[salvador-castro]

Great news on the RelWithDebInfo build — getting that working from the existing Conan cache without pulling extra artifacts is exactly the right outcome, and the Directory.Build.props approach for propagating include/lib paths globally is a solid pattern to keep in that solution.

On the screenshot you posted: I'd push back on that AI-generated answer fairly strongly. The claim that "no C++ IDE can perform mixed-mode debugging with Python 3.14" is an overstatement that conflates two separate things.

What Python 3.14 actually changed

PEP 768 (sys.remote_exec) introduced a safe external debugger interface — this is an addition, not a replacement of the internal CPython debug infrastructure. It gives external tools a sanctioned, ABI-stable attachment point without needing to parse raw CPython heap structures. The framing in that screenshot ("this architectural rewrite broke traditional mixed-mode IDE tools") is misleading. What it actually did was give debugger authors a better path forward. Visual Studio's PTVS mixed-mode engine has historically worked by reading CPython internals via the Python PDB symbols shipped alongside the interpreter — it doesn't rely on the fragile memory-layout hacks that were the real fragility point in older approaches. Whether PTVS has been updated to fully leverage the 3.14 interface depends on your VS version, but "broke" is not the right word.

More importantly for your situation: you're likely not on Python 3.14

Basilisk's CI and the pybind11 version it pins almost certainly target Python 3.10–3.12. If you installed Python from python.org for this project, you're probably on 3.11 or 3.12, where Visual Studio's mixed-mode debugger works without any of the 3.14 caveats. Check python --version in the VS developer prompt to confirm. The AI answer was responding to a generic question and has no knowledge of your actual setup.

Where you are and what to do next

Since you now have a working RelWithDebInfo build, here's the exact sequence to get mixed-mode stepping working in Visual Studio:

1. Set your Python script as the startup item. In the Solution Explorer, right-click the project that corresponds to your top-level Basilisk Python entry point → Set as Startup Project. Under Properties → Debugging, set:

   • Command: path to your Python executable (the same one Conan resolved against)
   • Command Arguments: your .py script and any flags
   • Working Directory: your repo root or wherever BSK expects it

2. Enable native code debugging. In that same Debugging properties page, check "Enable native code debugging". This is the toggle that activates the PTVS mixed-mode engine — without it, VS will only show Python frames and treat the C++ extension as a black box.

3. Verify PDBs are being found. Go to Debug → Windows → Modules while stopped at a breakpoint. Look for your Basilisk .pyd / .dll modules — the Symbol Status column should say "Symbols loaded" not "Skipped" or "Cannot find". If they're not loading, add your RelWithDebInfo output directory to Debug → Options → Debugging → Symbols → Symbol file locations.

4. Set a breakpoint on the C++ side. Open a .cpp file that you know gets called from Python (e.g. a pybind11-wrapped method), set a breakpoint, and run. If everything is wired up correctly, execution will break there when Python calls through into it, and you'll see both the Python call stack and the C++ frame in the call stack window simultaneously.

5. If breakpoints in C++ show as "not yet bound" (hollow circles). This usually means the PDB isn't matched to the binary. Confirm that your RelWithDebInfo build is actually producing .pdb files alongside the .dll/.pyd outputs, and that the binary VS is loading is the one from that build and not a stale Release copy somewhere on PATH or in site-packages.

On your Conan / CMake bug observation

You're right that the Windows Conan script has a bug where the CMake invocation ignores the debug build type flag and hardcodes Release. That's worth filing as a separate issue with a minimal repro — it affects anyone trying to use conan build -s build_type=RelWithDebInfo cleanly. Your workaround of starting from a successful Release build and manually patching the VS project is a legitimate short-term fix, but the root cause in the CMake/Conan glue should be addressed upstream.

Feel free to share the image from your last update if it shows a specific error or the debugger state — happy to help diagnose further from there.