#debugpy becomes unresponsive after rapid breakpoint suspend/resume cycles in multithreaded Python programs

Start with the minimal multithreaded reproduction and trace breakpoint handling through pydevd_sys_monitoring._stop_on_breakpoint and _do_wait_suspend. Compare suspend, rapid Continue requests, thread-state cleanup, and DAP event ordering under repeated cycles. Done means the session remains responsive and breakpoints continue to behave normally without requiring a restart.

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

1. Open the script in VS Code.
2. Set a breakpoint on time.sleep(1) inside worker().
3. Start debugging with F5.
4. When the breakpoint is hit, press F5 (Continue).
5. Repeat rapid F5 Continue operations.
6. 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:

1. Rapid suspend/resume cycles?
2. Multiple threads hitting the same breakpoint?
3. Thread state cleanup after continue?
4. DAP event ordering?