Cant remote attach debugger on Kodi 19 and VSCode

[davidbellemare]

Environment data

• debugpy version: 1.6.3
• OS and version: Ubuntu 22.04 LTS
• Python version (& distribution if applicable, e.g. Anaconda): 3.10.4
• Using VS Code

Actual behavior

Cannot attach remote debugger on localhost 5678 using the Attach config from VSCode. It hangs and never seems to completly attach to it. By quickly looking at the logs, it seems to accept the connection but VSCode never seems to attach really.

Kodi addon sample:
import debugpy
debugpy.log_to('/tmp/')
debugpy.listen(5678)
debugpy.wait_for_client() # blocks execution until client is attached

VSCode using default "Python: Remote Attach":

That same recipe was working with ptvsd and old python 2.7.

Expected behavior

VSCode attaching to process and then hit breakpoints.

Steps to reproduce:

1. Run Kodi addon that run snippet to start debugpy server
2. Attach to localhost 5678 from VSCode

Logs:
debugpy.adapter-5963.log
debugpy.server-5898.log

[davidbellemare]

@djay Were you able to attach and debug (hit breakpoints) finally?

#532 (comment)

[fabioz]

My guess from looking at the logs is that the path mapping is the issue. You should use full paths there for local/remote (not .).

i.e.: remoteRoot isn't ok there.

"pathMappings": [
     {
         "localRoot": "/home/johndoe/.kodi/addons/plugin.video.myaddon",
         "remoteRoot": "."
     }
 ]

If this doesn't fix it, please provide the pydevd logs too. You can get them by setting the following environment variables:

PYDEVD_DEBUG=True
PYDEVD_DEBUG_FILE=/tmp/pydevd.log

Ensure that the /tmp/ directory exists.

[fabioz]

As a note, if you're debugging in the same machine (and not in a different VM/computer) you probably shouldn't add any pathMappings.

[djay]

@davidbellemare yes I was able to in the end. but I haven't run it in awhile so not sure if I remember how I did it.

[davidbellemare]

@djay If you have a chance to test it that would be appreciated :) I do not see what is wrong. It used to work perfectly with the old ptvsd package :(

[davidbellemare]

As a note, if you're debugging in the same machine (and not in a different VM/computer) you probably shouldn't add any pathMappings.

Alright, indeed im on the same machine. These are the defaults generated by vscode. I will try tonight without that section.

[davidbellemare]

@fabioz I tried without any pathMapping but same result...:(

Here are the logs (I dont see much from the pydevd log thought...)
debugpy.adapter-8600.log
debugpy.server-8546.log
pydevd.8546.log

[int19h]

It looks like there was some breakdown in communication between the adapter and pydevd - from the log, the former sends "pydevdAuthorize" and is sitting waiting for response, while the latter received the request and sent the response, but it never shows up on the other end. So eventually the session just times out.

Of note is that the last line in the pydevd log is this:

Successfully Loaded helper lib to set tracing to all threads.

Normally this should be followed immediately by a bunch of messages along the lines of "SKIP tracing for frame", when pydevd walks the stacks and registers its trace handler where appropriate. The fact that it didn't do so leads me to suspect that pydevd crashed at the point it tried to use the native helper lib.

To test this, try setting PYDEVD_LOAD_NATIVE_LIB=0 for the Kodi process (it won't do anything on VSCode side!) - does that make any difference?

[davidbellemare]

@int19h Wow It did worked by setting PYDEVD_LOAD_NATIVE_LIB=0 for Kodi. VSCode was able to attach to the process and break. Thank you very much for your help :)

[int19h]

I don't know much about Kodi - do they use the system Python to run addons, or bundle & embed their own?

[davidbellemare]

They embed their own. You can't call the python interpreter directly. Its within kodi executable.

[int19h]

Then the most likely explanation is that they've customized theirs (e.g. with build options). Those native bits have to deal with some fairly low-level stuff in the interpreter, so it's possible that it breaks the debugger even if they managed to preserve public ABI compatibility.

The good news is that those native libs are there mainly for performance reasons - when you disable them (or on architectures for which they aren't compiled), everything works the same, just slower. There are some minor features that do require native code, like native thread detection or attach-by-PID, but hopefully they aren't relevant here.