[Investigate] Remote attach without launching adapter subprocess

[RockShea]

Environment data

• debugpy version: 1.2.1
• OS and version: Windows 10 Pro
• Python version (& distribution if applicable, e.g. Anaconda): Python27 embedded into 3DsMax 2018
• Using VS Code or Visual Studio: VSCode

Actual behavior

Remote attach times out from 3DsMax 2018 - which runs embedded Python27.
Here is the stacktrace, from 3DsMax 2018:

Traceback (most recent call last):
  File "C:\p4\Tools\Art\Python\!Shared\Development\R_Shared\R_Debugger.py", line 27, in start
    debugpy.listen(inAddress)
  File "C:\p4\Tools\Python\environment\2.7\Lib\site-packages\debugpy\__init__.py", line 113, in listen
    return api.listen(address)
  File "C:\p4\Tools\Python\environment\2.7\Lib\site-packages\debugpy\server\api.py", line 143, in debug
    log.reraise_exception("{0}() failed:", func.__name__, level="info")
  File "C:\p4\Tools\Python\environment\2.7\Lib\site-packages\debugpy\server\api.py", line 141, in debug
    return func(address, settrace_kwargs, **kwargs)
  File "C:\p4\Tools\Python\environment\2.7\Lib\site-packages\debugpy\server\api.py", line 232, in listen
    raise RuntimeError("timed out waiting for adapter to connect")
RuntimeError: timed out waiting for adapter to connect

And the error message in VSCode:

Expected behavior

Remote attach to correctly connect, as it does with 3DsMax 2021 - which runs embedded Python 37.

Steps to reproduce:

VSCode config settings which work in 3DsMax 2021 - Python37, but not 3DsMax 2018 - Python27:

"configurations": [
    {
        "name": "Python: Remote Attach",
        "type": "python",
        "request": "attach",
        "port": 3000,
        "host": "0.0.0.0",
        "pathMappings": [
            {
                "localRoot": "C:/p4/Tools/Art/Python",
                "remoteRoot": "C:/p4/Tools/Art/Python"
            }
        ]
    },
}

Code to run within 3DsMax, which works in 2021 - Python37 and not 2018 - Python27:

import debugpy
import os
import traceback


def start(inAddress, waitForAttach=False):

    try:

        debugpy.configure(python=<externalPythonPath>)
        debugpy.listen(inAddress)
        if waitForAttach:

            print("Waiting for debugger to attach...")
            debugpy.wait_for_client()

    except Exception:

        traceback.print_exc()


def stop():

    return


if __name__ in ("__main__", "__builtin__"):

    start(("0.0.0.0", 3000), waitForAttach=False)

[int19h]

0.0.0.0 means "listen on all known interfaces on the specified port". But when connecting, you need to specify the specific address to connect to - I'm not even sure what 0.0.0.0 is supposed to mean when it's used for a client socket, but it can't be right.

If you're connecting to 3DS Max instance that's running on the same machine as VSCode, you should be using 127.0.0.1 on both sides. Also note that listening on 0.0.0.0 means that anybody who can connect to your machine over the network to the port it's listening on, can debug it - unless you're on a private secure network, you really don't want to do that, because the debugger allows execution of arbitrary code (via e.g. Watch).

[RockShea]

Thanks for the reply @int19h

VSCode and the instance of Max are on the same machine - thankfully we are on a private secure network. Thanks for the information though, that is good to know.
I found the suggestion to use 0.0.0.0 on other threads with connection issues.
Unfortunately, if I swap the address to localHost or 127.0.0.1 the problem persists.
Would the use of 0.0.0.0 not illustrate that there is a problem on Py27 as it still not connecting even if it is listening on all ports?

Stacktrace from within Max2018:

Traceback (most recent call last):
  File "C:\p4\Tools\Art\Python\!Shared\Development\R_Shared\R_Debugger.py", line 28, in start
    debugpy.listen(inAddress)
  File "C:\p4\Tools\Python\environment\2.7\Lib\site-packages\debugpy\__init__.py", line 113, in listen
    return api.listen(address)
  File "C:\p4\Tools\Python\environment\2.7\Lib\site-packages\debugpy\server\api.py", line 143, in debug
    log.reraise_exception("{0}() failed:", func.__name__, level="info")
  File "C:\p4\Tools\Python\environment\2.7\Lib\site-packages\debugpy\server\api.py", line 141, in debug
    return func(address, settrace_kwargs, **kwargs)
  File "C:\p4\Tools\Python\environment\2.7\Lib\site-packages\debugpy\server\api.py", line 232, in listen
    raise RuntimeError("timed out waiting for adapter to connect")
RuntimeError: timed out waiting for adapter to connect

Error message in VSCode:

Supporting Py27 is a pain, unfortunately we are stuck with it due to the software we use having it as it's embedded version.

[int19h]

Listening on 0.0.0.0 is fine (security aside), it's connecting that has unclear semantics. It should be okay to listen on 0.0.0.0, but connect to 127.0.0.1. In your case, since it's all local, 127.0.0.1 is the right choice for both ends. It is also the default if you specify the port, but omit the host.

[int19h]

Can you double-check that the version of Python interpreter that you're passing to debugpy.configure() is valid? Note that it doesn't have to match the version of Python used by the app - any version supported by debugpy should do.

If that's the case, then we'll need logs to figure out what's going on here. You can get those by doing:

debugpy.log_to(r'C:\Temp')  # must be a directory

The resulting log files will be named debugpy*.log.

[RockShea]

The standalone interpreter is a studio distribution of Python37, which has debugpy installed on it.
I use the same version for Max2018 and 2021.
I will setup the log file and see what it reports.

Thanks again for the help.

[RockShea]

Here is the log file generated from within 3DsMax 2018:
debugpy.server-10580.log
Am I able to generate any log from within VSCode?

[int19h]

The most interesting log in this case is the one that comes from the adapter, but it looks like it didn't even get to the point where it started logging. But it might be possible to diagnose this manually by replicating what the server is trying to do; specifically:

I+00000.006: debugpy.listen() spawning adapter: [
                 "C:\\p4\\Tools\\Python\\environment\\3.7\\Scripts\\python.exe", 
                 "C:\\p4\\Tools\\Python\\environment\\2.7\\Lib\\site-packages\\debugpy\\adapter", 
                 "--for-server", 
                 "61270", 
                 "--host", 
                 "localHost", 
                 "--port", 
                 "3000", 
                 "--server-access-token", 
                 "4d0918d8f29ed47123d016bc38618bea1a86cb0dc6b335a23630c2eca6511780", 
                 "--log-dir", 
                 "C:\\p4\\Tools\\Art\\Data\\Debugger"
             ]

Can you try running this same thing manually in the terminal, and see what errors (if any) it produces?

[RockShea]

So if I run debugpy in our Python27 venv it seems to work correctly:

C:\P4\Tools\Python\environment\2.7\Scripts\activate
python -m debugpy --listen localhost:3000 --log-to -debug folder path- -site setup .py file-

It seems to work without issue and generates two log files:
debugpy.adapter-4188.log
debugpy.server-17940.log

[int19h]

Interesting. Sounds like Python version mismatch is a problem in this scenario. This is unexpected, and I'll take a look at what breaks there, but for now, I guess this is the workaround. Thank you for your help in diagnosing this!

[RockShea]

Ah - that is good that you have spotted an issue!
Thanks for the quick support :)
Just to confirm, the workaround you suggest is using the command line to debug?

[djay]

I'm having similar problems with Kodi on macos. Why does debugpy have to spawn? it would be very nice if it supported a non-spawn mode to make life simpler. I just want to set a set_trace().

Kodi on macos doesn't have a command line interpreter as far as I can tell. It's embedded.

$ /Applications/Kodi.app/Contents/MacOS/Kodi 
2021-02-03 02:54:06.175 XBMCHelper[8457:4490273] ParseOptions - force VerboseMode on
2021-02-03 02:54:06.175 XBMCHelper[8457:4490273] ParseOptions - ReadExternal on
2021-02-03 02:54:06.176 XBMCHelper[8457:4490273] ParseOptions - force VerboseMode on
2021-02-03 02:54:06.176 XBMCHelper[8457:4490273] ParseOptions - server port 9777
2021-02-03 02:54:06.176 XBMCHelper[8457:4490273] ParseOptions - AppPath /Applications/Kodi.app/Contents/MacOS/Kodi
2021-02-03 02:54:06.176 XBMCHelper[8457:4490273] ParseOptions - AppHome /Applications/Kodi.app/Contents/Resources/Kodi
2021-02-03 02:54:06.176 XBMCHelper[8457:4490273] XBMCHelper 0.8 starting up...
2021-02-03 02:54:06.234 XBMCHelper[8457:4490273] [ERROR] Driver has not found any remotes it could use. Will use remotes as they become available.
Traceback (most recent call last):
  File "/Users/Shared/jenkins/workspace/OSX-64_Leia/tools/depends/xbmc-depends/macosx10.13_x86_64-target-release/lib/python2.7/runpy.py", line 174, in _run_module_as_main
  File "/Users/Shared/jenkins/workspace/OSX-64_Leia/tools/depends/xbmc-depends/macosx10.13_x86_64-target-release/lib/python2.7/runpy.py", line 72, in _run_code
  File "/Users/dylanjay/Projects/kodi/debugpy/src/debugpy/adapter/__main__.py", line 7, in <module>
    import argparse
  File "/Users/Shared/jenkins/workspace/OSX-64_Leia/tools/depends/xbmc-depends/macosx10.13_x86_64-target-release/lib/python2.7/argparse.py", line 85, in <module>
  File "/Users/Shared/jenkins/workspace/OSX-64_Leia/tools/depends/xbmc-depends/macosx10.13_x86_64-target-release/lib/python2.7/collections.py", line 20, in <module>
ImportError: No module named _collections

Note /Users/Shared/jenkins/workspace/OSX-64_Leia/tools/depends/xbmc-depends/macosx10.13_x86_64-target-release/ doesn't exist on my machine.

Config is

        import collections # Just to show it is there
        import debugpy
        debugpy.configure(
            subProcess=True,
            python="/usr/local/bin/python",
        )
        debugpy.listen(5678)

$ cat ~/logs/debugpy.server-8450.log 
I+00000.023: Darwin-19.6.0-x86_64-i386-64bit x86_64
             CPython 2.7.15 (64-bit)
             debugpy 1.2.1+9.gcbcfe22

I+00005.960: Initial environment:
             
             System paths:
                 sys.prefix: /Applications/Kodi.app/Contents/Libraries
                 sys.base_prefix: <missing>
                 sys.real_prefix: <missing>
                 site.getsitepackages(): /Applications/Kodi.app/Contents/Libraries/lib/python2.7/site-packages
                                         /Applications/Kodi.app/Contents/Libraries/lib/site-python
                 site.getusersitepackages(): /Users/dylanjay/.local/lib/python2.7/site-packages
                 sys.path (site-packages): /Applications/Kodi.app/Contents/Libraries/lib/python2.7/site-packages
                                           /Users/dylanjay/.local/lib/python2.7/site-packages
                 sysconfig.get_path('stdlib'): /Applications/Kodi.app/Contents/Libraries/lib/python2.7
                 sysconfig.get_path('platstdlib'): /Applications/Kodi.app/Contents/Libraries/lib/python2.7
                 sysconfig.get_path('purelib'): /Applications/Kodi.app/Contents/Libraries/lib/python2.7/site-packages
                 sysconfig.get_path('platlib'): /Applications/Kodi.app/Contents/Libraries/lib/python2.7/site-packages
                 sysconfig.get_path('include'): /Applications/Kodi.app/Contents/Libraries/include/python2.7
                 sysconfig.get_path('scripts'): /Applications/Kodi.app/Contents/Libraries/bin
                 sysconfig.get_path('data'): /Applications/Kodi.app/Contents/Libraries
                 os.__file__: /Applications/Kodi.app/Contents/Libraries/lib/python2.7/os.pyo
                 threading.__file__: /Applications/Kodi.app/Contents/Libraries/lib/python2.7/threading.pyo

D+00005.974: configure(None, {'python': '/usr/local/bin/python', 'subProcess': True})

D+00006.003: listen((u'127.0.0.1', 5678), **{})

I+00006.005: Initial debug configuration: {
                 "python": "/usr/local/bin/python", 
                 "qt": "none", 
                 "subProcess": true
             }

I+00006.074: Waiting for adapter endpoints on 127.0.0.1:64508...

I+00006.076: debugpy.listen() spawning adapter: [
                 "/usr/local/bin/python", 
                 "/Users/dylanjay/Library/Application Support/Kodi/addons/script.module.ptvsd/lib/debugpy/adapter", 
                 "--for-server", 
                 "64508", 
                 "--host", 
                 "127.0.0.1", 
                 "--port", 
                 "5678", 
                 "--server-access-token", 
                 "99af9c3f27dfdd19553fa3e242a12400ff985bc45f10813c3591c59ab2d866ee", 
                 "--log-dir", 
                 "/Users/dylanjay/logs"
             ]

I+00013.148: Timed out waiting for adapter to connect:
...

$ cat ~/logs/debugpy.pydevd.8450.log 
os.path.exists('/Users/Shared/jenkins/workspace/OSX-64_Leia/tools/depends/xbmc-depends/macosx10.13_x86_64-target-release/lib/python2.7/posixpath.py') returned False.
It seems the debugger cannot resolve /Users/Shared/jenkins/workspace/OSX-64_Leia/tools/depends/xbmc-depends/macosx10.13_x86_64-target-release/lib/python2.7/posixpath.py
This may make the debugger miss breakpoints in the standard library.
Related bug: https://bugs.python.org/issue1180193
Using GEVENT_SUPPORT: False
pydevd __file__: /Users/dylanjay/Library/Application Support/Kodi/addons/script.module.ptvsd/lib/debugpy/_vendored/pydevd/pydevd.pyo

And no adapter log generated

If I run the adapter command line manually it seems to work fine

$ /usr/local/bin/python /Users/dylanjay/Library/Application\ Support/Kodi/addons/script.module.ptvsd/lib/debugpy/adapter
Content-Length: 148

{"seq": 1, "type": "event", "event": "output", "body": {"category": "telemetry", "output": "ptvsd", "data": {"packageVersion": "1.2.1+9.gcbcfe22"}}}Content-Length: 150

{"seq": 2, "type": "event", "event": "output", "body": {"category": "telemetry", "output": "debugpy", "data": {"packageVersion": "1.2.1+9.gcbcfe22"}}}

[RockShea]

I was able to get it to work by having the external Python interpreter match the version of the embedded version:

def start(inAddress, waitForAttach=False, log=False):
    """Start the debugger in the current python interpreter.
    This allows connection from a remote debugger, such as Sublime or VSCode.

    Args:
        inAddress (int): Port or address: port to connect to.
            Either ("0.0.0.0", 3000) or 3000
        waitForAttach (bool, optional): If True, will block program execution
            until the debugger is attached.
            Defaults to False.

    Returns:
        bool: True on success, False on failure.
    """

    try:

        if log:

            debugpy.log_to(os.path.join(RockToolsPathData.toolsData, "Debugger"))

        pythonExecutable = (
            os.path.join(RockToolsPathData.toolsPython, "environment\\3.7\\Scripts\\python.exe")
            if __py3__
            else os.path.join(RockToolsPathData.toolsPython, "environment\\2.7\\Scripts\\python.exe")
        )
        debugpy.configure(python=pythonExecutable)
        debugpy.listen(inAddress)
        if waitForAttach:

            print("Waiting for debugger to attach...")
            debugpy.wait_for_client()

    except Exception:

        traceback.print_exc()

[int19h]

@djay It has to spawn because some things that debugger needs to do, cannot be done reasonably well from within the same process that is being debugged. The older versions (pre-ptvsd 5.x) didn't have a multiproc architecture, and there was a slew of bugs and limitations stemming from that.

And, unfortunately, it's a fairly fundamental architectural decision, so we can't easily support a "no-spawn mode" or something like that for debugpy. Although it might be possible to use pydevd as a standalone DAP server at this point - it might be fully compatible with VSCode by now even without debugpy in the picture. @fabioz, can you advise?

Also note that you don't need the interpreter offered by the app doing the embedding. You just need some Python interpreter, somewhere. As @RockShea noted above, at the moment, it seems to only work correctly if the language version matches (although that wasn't intended). So, you just need to install a matching version of Python, and then use debugpy.configure() to point at that.

[djay]

@int19h I'm not sure the language version is the problem in this case. how close do they have to be?
The system python I am pointing to is '2.7.17 (default, Oct 24 2019, 12:57:47) \n[GCC 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.8)]'.
The logs above seem to indicate the embedded kodi interpreter is Darwin-19.6.0-x86_64-i386-64bit x86_64 CPython 2.7.15 (64-bit).
I can't see that changing my version to 2.7.15 instead of 2.7.15 is likely to solve the problem of ImportError: No module named _collections is it?
It seems more likely that something about how it is setting up the python paths to start the process is more likely to blame?
As you can see from me starting the server using the system python (without trying to adjust python paths etc) it seems to start fine.