Stepping in a multithreaded application jumps to other threads

[rchiodo]

Discussed in #1761

^{Originally posted by pub-pub December 10, 2024}
i posted my initial issue here and it was successfully resolved.

now i'm using "steppingResumesAllThreads": false setting for debugging. but this solutions has a drawback, it pauses all other threads.

is it possible to add one more setting that will keep debugger Stepping inside my initial thread without pausing all other threads?

[rchiodo]

Here's some source code to reproduce the problem:

import threading
import time
import requests

def request_get(url):
    # return "abc"
    with requests.get(url) as data:
        return data.text

def watcher():
    while True:
        print(1)
        time.sleep(3)

def worker ():
    while True:
        print(len(request_get("https://dns.google//")))
        time.sleep(5)

threading.Thread(daemon=True, target=watcher).start()
t1 = threading.Thread(target=worker)
t1.start()
t2 = threading.Thread(target=worker)
t2.start()
t1.join()
t2.join()

Set a breakpoint on line 11 (the print(1)) in the watcher and step. It will eventually end up in the other thread

[xmatthias]

I'm encountering the same - though in a pretty large codebase where so far i didn't take the time to create a reproduction.

It's not just "on step" for me, either - also the initial breakpoint may stop - shows you that code for a second - and then (as other threads stop) it'll jump to other parts of the code (other files, running in other threads), pulling me away from the code i wanted to look at / debug, having me go back to the original.
it's happening on step too - but it's not limited to "step" as far as i did experience.

it's driving me nuts if I'm honest - and I'm pretty certain that it wasn't the case a few months ago (I'm working on this same, multithreaded, partially async codebase since about 5 years now).

[tbrisker-april]

I've also been encountering the same issue recently, and it seems to be a regression introduced in the recent months, in the past there was no issue debugging a multithreaded app without the debugger jumping to other threads.

[rchiodo]

This might be a problem only related to 3.12 and above. #1792 indicated it started with the changes for sys.monitoring. I can't reproduce the issue with 3.11.

[xmatthias]

@rchiodo when is the next release planned? (this release will probably even not be sufficient, as i'd need it in the vscode extensions ...)

Considering the fixes in / around "fixed in next release" are quite impacting (IF you're impacted) - i'd apreciate this being fixed pretty short-term - as it makes debugging currently a very frustrating experience.

[rchiodo]

Next release will probably ship in the next week or so. I'm looking at some matplotlib problems too that I'd like to fix before the next release.

Note that you can "get" the fix yourself by just copying the source from main over your install of debugpy. There were no native changes in this fix, you just need the source code that ships with debupgy.

[rchiodo]

This issue should be fixed in the latest build of debugpy. It should ship with VS code in a future version of the Python Debugger Extension or you can install your own debugpy from pypi

[rchiodo]

Take that back, our release to PyPI failed when it looked like it succeeded. Fix will be coming after we resolve that problem.

[rchiodo]

PyPI release succeeded. v1.8.12 is now available