debugpy becomes unresponsive after rapid breakpoint suspend/resume cycles in multithreaded Python programs
Description
I found an issue where the debug session becomes unresponsive after repeatedly hitting a breakpoint and rapidly pressing F5 (Continue/Resume) in a multithreaded Python application.
The issue can be reproduced with a minimal example.
It does not appear to be specific to Python 3.14 free-threading, because the same behavior can also be reproduced on CPython 3.11.9.
The problem appears to be related to repeated breakpoint suspend/resume cycles and thread state handling inside debugpy/pydevd.
Environment
OS:
Windows 11
Debugger:
VS Code Python Debugger extension
debugpy: latest version
Python versions tested:
- CPython 3.11.9
- CPython 3.14.6
- CPython 3.14.6 free-threaded build (python3.14t)
Minimal Reproduction
import threading
import time
def worker():
while True:
x = 1
time.sleep(1) # Put breakpoint here
for i in range(2):
threading.Thread(target=worker).start()
while True:
time.sleep(1)
Steps to Reproduce
- Open the script in VS Code.
- Set a breakpoint on time.sleep(1) inside worker().
- Start debugging with F5.
- When the breakpoint is hit, press F5 (Continue).
- Repeat rapid F5 Continue operations.
- After several suspend/resume cycles, the debugger becomes unresponsive.
Expected Behavior
Breakpoint suspend/resume cycles should continue normally.
Actual Behavior
After several rapid F5 Continue operations:
- VS Code stops updating the current debug location.
- Breakpoints no longer behave normally.
- The debugger UI becomes stuck.
- Restarting the debug session is required.
Technical Observation
Breakpoint handling reaches:
_pydevd_sys_monitoring._stop_on_breakpoint
and:
_do_wait_suspend()
The suspend path is entered successfully.
Possible affected areas:
- pydevd suspend/resume state management
- debugpy adapter DAP event ordering
- handling of rapid continue requests
- multithreaded breakpoint synchronization
Questions
Could this be related to a race condition in debugpy regarding:
- Rapid suspend/resume cycles?
- Multiple threads hitting the same breakpoint?
- Thread state cleanup after continue?
- DAP event ordering?
debugpy becomes unresponsive after rapid breakpoint suspend/resume cycles in multithreaded Python programs
Description
I found an issue where the debug session becomes unresponsive after repeatedly hitting a breakpoint and rapidly pressing F5 (Continue/Resume) in a multithreaded Python application.
The issue can be reproduced with a minimal example.
It does not appear to be specific to Python 3.14 free-threading, because the same behavior can also be reproduced on CPython 3.11.9.
The problem appears to be related to repeated breakpoint suspend/resume cycles and thread state handling inside debugpy/pydevd.
Environment
OS:
Windows 11
Debugger:
VS Code Python Debugger extension
debugpy: latest version
Python versions tested:
Minimal Reproduction
Steps to Reproduce
Expected Behavior
Breakpoint suspend/resume cycles should continue normally.
Actual Behavior
After several rapid F5 Continue operations:
Technical Observation
Breakpoint handling reaches:
_pydevd_sys_monitoring._stop_on_breakpoint
and:
_do_wait_suspend()
The suspend path is entered successfully.
Possible affected areas:
Questions
Could this be related to a race condition in debugpy regarding: