1

Closed

Breakpoints don't bind when attaching w/ mixed mode debugging (Python 3.3?)

description

Attach to a Python process w/ mixed mode debugging. Call stack shows up fine w/ both C++ and Python frames, but setting a breakpoint (in the main file) leaves the breakpoint unbound reporting 'No symbols have been loaded for this document.' Breakpoints can be set in an imported file, and the main file doesn't show up in Debug->Modules.
Closed Sep 30, 2013 at 9:40 PM by pminaev
For now this is by design, but we are limited by Python interpreter design here. If the latter is improved wrt code object tracking, we should revisit.

comments

pminaev wrote Sep 30, 2013 at 7:27 PM

This needs more specific repro steps, as the basic scenario does work. At what point did the attach occur - was the code running in the main file at that point, or in one of imported modules? How was the main file started?

pminaev wrote Sep 30, 2013 at 9:39 PM

To repro, one needs to attach after the main thread is terminated, and atexit handlers are running (e.g. if one of those handlers blocks waiting for the keypress). At that point, the main module is considered unloaded, and is gone from sys.modules; however, some functions from it can still be running on background threads. If a function or class def (or anything else that would cause a creation of a new code object) is evaluated on one of those background threads after attach, the module will be detected and breakpoints will light up. In the repro, however, the background thread function is just sitting in a loop printing out things, and so there is no event causing the module to be registered as loaded.

A straightforward workaround would be to auto-register any unknown modules during a stack walk, but VS debugger doesn't like that.

Ideally, what we need is the ability to enumerate all live code objects in the process. That would also fix some other corner cases (e.g. breakpoints in code loaded via eval/exec before attach). Unfortunately, Python doesn't currently have such an API.