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

Bắt đầu với bản tái hiện đa luồng tối thiểu và lần theo việc xử lý breakpoint qua pydevd_sys_monitoring._stop_on_breakpoint và _do_wait_suspend. So sánh Suspend, các yêu cầu Continue nhanh, việc dọn dẹp trạng thái luồng và thứ tự sự kiện DAP qua các chu kỳ lặp lại. Hoàn thành khi phiên vẫn phản hồi và các breakpoint tiếp tục hoạt động bình thường mà không cần khởi động lại.

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?