Closed rttus closed 3 months ago
I have similar issues trying to stop on breakpoints using examples from this Brainflow example code.
As far as I can tell, breakpoints work until the code gets paste the brainflow
import statements. Breakpoints will work on any line of code up to the first brainflow
import statement and then all breakpoints are essentially invisible. This makes me wonder if there is something being changed behind the scenes of the Brainflow import that messes with the Python debugger and similarly in rttus's code too?
My only workaround that I have found to work is to use the actual breakpoint()
function into places in the code where I want to break after.
Thank you for sharing your workaround. If i use breakpoint()
it works for me as well.
Glad the workaround works for you too!
Wish I knew what was happening behind the scenes to make it so that actual code breakpoints in the gutter would work... =(
Thanks for your issue report, i'm not sure if the Python Debugger Extension handles that. @int19h do you have any idea what's going on?
I am not familiar with FastDDS, but if it spawns threads itself (i.e. those threads are not spawned via Python's threading
module), the debugger will not be aware of them, and thus will not be able to hit breakpoints on them. The workaround is to call debugpy.trace_this_thread()
as early as possible to notify the debugger.
That makes sense to me. Would libraries spawning threads stop debugpy from stopping on breakpoints on the main thread too?
In my case, I don't think the Brainflow libraries that I use spawn threads, but I'd have to look into that more. Is there other reasons that the debugger would no longer stop on breakpoints set in the gutter but would stop with the breakpoint()
function?
That makes lot of sense, i presume it would be the same for multiprocessing
module?
multiprocessing
and the rest of stdlib should work just fine. It's specifically the problem when a third party library spawns a new thread from native code, and then tries to run Python code on it. CPython itself handles this just fine, automatically initializing the thread as needed, but the debugger is unaware that there's a new thread it needs to be tracing. It should not affect any "normal" threads in the same process, though, including the main thread.
With respect to BrainFlaw, if breakpoints suddenly stop working after it gets imported, it is quite likely that it overrides the tracing hook via sys.settrace
for its own purposes - some packages do this for integrated debugging or diagnostic functionality of their own, but then that interferes with debugger operation.
Both issues are something that will go away with the new debugger architecture in debugpy v2 (but the cost of that will be requiring Python 3.12+).
Hi,
I am trying to run this multithread publisher subscriber code https://fast-dds.docs.eprosima.com/en/latest/fastdds/getting_started/simple_python_app/simple_python_app.html Below is the code for quick reference.
I am running into the issue where breakpoint in the function on_data_available in the subscriber code is not hit. Below is my vscode and extension version. Please help.
Version: 1.86.2 (Universal) Commit: 903b1e9d8990623e3d7da1df3d33db3e42d80eda Date: 2024-02-13T19:42:13.651Z Electron: 27.2.3 ElectronBuildId: 26908389 Chromium: 118.0.5993.159 Node.js: 18.17.1 V8: 11.8.172.18-electron.0 OS: Darwin arm64 23.3.0