QThread debugging regression after version 1.1.0

[dtasev]

Environment data

• debugpy version: 1.2.1 (run import debugpy; print(debugpy.__version__) if uncertain)
• OS and version: Ubuntu 18.04
• Python version (& distribution if applicable, e.g. Anaconda): 3.7.8, Anaconda x64
• Using VS Code or Visual Studio: VS Code

Actual behavior

Breakpoints are not getting hit when reached from a child thread.

This seems to be a regression after version 1.1.0 (shipped with VSCode Python 2020.11.358366026). Updating the Python extension to any version after 2020.11.358366026 (which seem to ship 1.2.0 onwards) breaks this.

Rolling back to 2020.11.358366026 (with 1.1.0) and the debugging works again.

I have tried adding "subProcess": true but it seems that it doesn't fix this bug in 1.2.0, nor is it required when using 1.1.0 to breakpoint from a child thread.

Expected behavior

Breakpoints are hit in child threads the same way in 1.1.0 and 1.2.0 onwards

Steps to reproduce:

Note this uses a QThread because the issue was encountered in debugging an async core task of a GUI. I am not sure whether a Python thread would work here. To get PyQt5 do pip install PyQt5==5.15.1

from PyQt5 import Qt


class TaskWorkerThread(Qt.QThread):
    def __init__(self, task_function):
        super(TaskWorkerThread, self).__init__()
        self.task_function = task_function

    def run(self):
        self.result = self.task_function()


def debugging_function():
    print(123)


thread = TaskWorkerThread(debugging_function)
thread.start()

And launch.json

    {
      "name": "Python: Current File",
      "type": "python",
      "request": "launch",
      "program": "${file}",
      "console": "integratedTerminal",
      "subProcess": true
    },

1. Upgrade to the latest Python extension (or any that ship debugpy 1.2.0 or later)
2. Copy paste into a file & put a breakpoint on print(123)
3. The process should just exit and the breakpoint will never be triggered
4. Downgrade to Python VSCode 2020.11.358366026
5. Repeat - you should now see the breakpoint on print(123) trigger
   • Although the server will then exit and stop the debugger as if the process has finished. This might be a separate issue but this bug report is not concerned with that - as long as there is a significant amount of work in the subthread task, then it works fine.

[fabioz]

I think the issue is that we don't automatically patch qt threads anymore (as it should work when the compiled extensions from the debugger are available in Python 3.6 -- as it's not working for you, the compiled extensions are probably not available).

See: #304 (comment) for how to set things up in this case.

[dtasev]

Thanks, adding "qt": "auto" worked! I did see some bug (#362) mentioned in the release notes related to that launch option, but because it was highlighted as unknown (due to microsoft/vscode-python#12535) I didn't think of running the configuration to try it out. That won't be an issue when it gets the schema gets merged in.

[fabioz]

@karthiknadig @int19h are the compiled extensions currently being distributed by default? If they're not we should probably check that so that native thread tracing works out of the box on 3.6 onwards.

[int19h]

It depends on the scenario. When debugpy is published to PyPI, we upload wheels for all supported Python versions. But the version that's bundled with vscode-python only has binaries for Python 3.8 (for all supported platforms). The main reason why it doesn't include them all is because those binaries are fairly large - as it stands, debugger is already almost as big as the rest of the extension already. So if we included binaries for all supported version/platform combos, it would make the extension several times bigger. A better way to solve this would be downloading the debugger on demand.

[fabioz]

On PyDev I end up distributing only for Windows (I took a look and for Win 32+Win 64 for Python 2.7, and 3.6->3.9 it takes 4.5MB) and on Linux/Mac it shows a command line for how to build it locally. I just took a look at the shipped version in debugpy and a single linux binary for amd_64 is 5.5MB... I'm not sure why it gets so big on Linux, it definitely seems like something is off there -- I'll try to take a look at #169 to investigate that after the current issue I'm working on (if it can be trimmed down maybe it'd make sense to include for more python versions).

If that doesn't work out, I like the idea of the downloading it for the user on demand though (having the user compile it locally isn't ideal on the cases where the user doesn't have the compiler toolchain setup).