Timeout waiting for debugger connection to running pythonnet process

s-seele commented 11 months ago

Environment data

debugpy version: 1.8.0
OS and version: Windows 11, Version 10.0.22621, Build 22621
Python version (& distribution if applicable, e.g. Anaconda): >=3.11
Using VS Code or Visual Studio: VS Code 1.84.2, python extension v2023.20.0

Actual behavior

The debugger is unable to attach, giving the following error message: Timed out waiting for debug server to connect

Expected behavior

The debugger successfully attaches to the running process.

Steps to reproduce:

We're running python scripts from within a .NET application using pythonnet 3.0.3. To enable the VS Code debugger to connect to our process, we do the following before the actual script is run: import sys import time while not sys.gettrace(): time.sleep(0.1)

We use the following launch.json to attach to the process: { "name": "Attach Script Debugger", "type": "python", "request": "attach", "processId": "${command:pickProcess}", "justMyCode": true }

Using this approach, it has been possible to attach the debugger to our process up until Python 3.10. Nothing changed other than that we upgraded to pythonnet 3.0.3 from 3.0.1 and that we used a different Python version. Attaching to the debugger still works for 3.10 with the upgraded pythonnet library.

I also tried adding "subProcess": true and "timeout": 300000 to the launch.json as well as changing the default terminal to Cmd.exe and setting "python.terminal.activateEnvironment" to false, as suggested in other issues.

The respective Python version is added to the system PATH variable and matches the selected interpreter in VS Code. pythonVSCodeVersion

Here are the logfiles, but they don't seem to be very helpful. debugger.vscode_forPython311.log debugpy.adapter_forPython311.log

int19h commented 11 months ago

Out of curiosity, why not use debugpy.listen() and debugpy.wait_for_client(), and connect using attach to socket? This is generally more reliable than attach-to-PID - the latter eventually boils down to socket attach anyway, but it has to do some very hacky things first to get that Python code injected.

s-seele commented 11 months ago

Thanks for the quick response. It was already implemented like that when I started taking a look at it. I tried using listen(5678) and wait_for_client. When I run a script with that from the command line, I can attach to it using VS Code with the following launch.json:

{
    "name": "Python: Remote Attach",
    "type": "python",
    "request": "attach",
    "connect": {
        "host": "127.0.0.1",
        "port": 5678
    },
    "pathMappings": [
        {
            "localRoot": "${workspaceFolder}",
            "remoteRoot": "${workspaceFolder}"
        }
    ],
    "justMyCode": true
}

However, when I try to attach to the script being run from our process using this approach, I get the following error: connect ECONNREFUSED 127.0.0.1:5678

When trying to attach from the command line, I get this output:

0.01s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Users\#########\AppData\Roaming\Python\Python312\site-packages\debugpy\__main__.py", line 39, in <module>
    cli.main()
  File "C:\Users\#########\AppData\Roaming\Python\Python312\site-packages\debugpy\server\cli.py", line 430, in main
    run()
  File "C:\Users\#########\AppData\Roaming\Python\Python312\site-packages\debugpy\server\cli.py", line 284, in run_file
    runpy.run_path(target, run_name="__main__")
  File "C:\Users\#########\AppData\Roaming\Python\Python312\site-packages\debugpy\_vendored\pydevd\_pydevd_bundle\pydevd_runpy.py", line 321, in run_path
    return _run_module_code(code, init_globals, run_name,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\#########\AppData\Roaming\Python\Python312\site-packages\debugpy\_vendored\pydevd\_pydevd_bundle\pydevd_runpy.py", line 135, in _run_module_code
    _run_code(code, mod_globals, init_globals,
  File "C:\Users\#########\AppData\Roaming\Python\Python312\site-packages\debugpy\_vendored\pydevd\_pydevd_bundle\pydevd_runpy.py", line 124, in _run_code
    exec(code, run_globals)
  File "Test.py", line 1, in <module>
    print(input1)
          ^^^^^^
NameError: name 'input1' is not defined. Did you mean: 'input'?

input1 is the name of the input provided from within our own process.

int19h commented 11 months ago

The behavior of python -m debugpy ... foo.py should match that of python foo.py exactly, so this indicates a bug on our end. Could you clarify how input1 is defined?

microsoft / debugpy