DEBUGPY_ADAPTER_ENDPOINTS being invalid should output an error

[dobos]

Before creating a new issue, please check the FAQ to see if your question is answered there.

Environment data

• debugpy version: 1.8.7
• OS and version: CentOS 8.5
• Python version: Python 3.10.15 from conda-forge
• Using VS Code or Visual Studio: --

Actual behavior

I'm starting debugby from the command line using

$ python -m debugpy --log-to-stderr --listen 127.0.0.1:5799 --wait-for-client -c 'print("hello world!")'

The adapter appears to be started and it reports the port number 5799 but when I want to connect to the port I get ECONNREFUSED in vscode. If I check with netstat the port is not open. If I list the running processes the debugpy adapter is not among them so my guess is that it fails right after opening the port.

When I run the above command with sudo, the adapter is started up correctly and the port can be accessed, the adapter process is listed by ps

Expected behavior

Adapter start up properly in user mode

Steps to reproduce:

I'm no aware of any way to reproduce the error outside my server. I've disample SELinux to make sure ports can be opened by user mode processes to no avail. This is an issue that started happening a few days ago and I'm not aware of any system updates.

[dobos]

I've also updated by environment to debugpy version 1.8.13 but the issue is still there. If there was any way to pass arguments to the adapter, I could see the error messages from the adapter itself.

[dobos]

Further investigating the issue: it seems that the adapter does start when it's initiated from code instead of calling debugpy from the command-line.

[dobos]

Here's some more info. The issue seems to happen only when I start the process I want to debug from the integrated terminal. When I logon to the remote linux server from a simple command-line terminal, the debug adapter starts properly and binds to the tcp port. This is how my environment looks like when using stand-alone ssh (clutter and IP addresses removed:

LS_COLORS=
SSH_CONNECTION=*.*.*.* 55154 *.*.*.* 22
LANG=en_US.UTF-8
HISTCONTROL=ignoredups
HOSTNAME=volta04.*.*.*
SSH_AUTH_SOCK=/tmp/ssh-Lii8o4lXG4/agent.784182
which_declare=declare -f
XDG_SESSION_ID=37
USER=dobos
PWD=/home/dobos
HOME=/home/dobos
SSH_CLIENT=*.*.*.* 55154 22
SSH_TTY=/dev/pts/22
MAIL=/var/spool/mail/dobos
TERM=xterm-256color
SHELL=/bin/bash
CUDA_VISIBLE_DEVICES=4,5,6,7
SHLVL=1
LOGNAME=dobos
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1897/bus
XDG_RUNTIME_DIR=/run/user/1897
PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/usr/local/texlive/2023/bin/x86_64-linux
HISTSIZE=1000
LESSOPEN=||/usr/bin/lesspipe.sh %s
BASH_FUNC_which%%=() {  ( alias;
 eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot "$@"
}
_=/usr/bin/env

And this is the environment when working with the intergrated terminal:

CONDA_SHLVL=0
LS_COLORS=
CONDA_EXE=/datascope/slurm/miniconda3/bin/conda
SSH_CONNECTION=*.*.*.* 47682 *.*.*.* 22
LANG=en_US.UTF-8
HISTCONTROL=ignoredups
HOSTNAME=volta04.*.*.*
COLORTERM=truecolor
VSCODE_GIT_ASKPASS_EXTRA_ARGS=
VSCODE_DEBUGPY_ADAPTER_ENDPOINTS=/home/dobos/.vscode-server/extensions/ms-python.debugpy-2025.4.0-linux-x64/.noConfigDebugAdapterEndpoints/endpoint-58a7f9bb4e53a911.txt
SSH_AUTH_SOCK=/run/user/1897/vscode-ssh-auth-sock-843961051
_CE_M=
which_declare=declare -f
XDG_SESSION_ID=31
USER=dobos
DEBUGPY_ADAPTER_ENDPOINTS=/home/dobos/.vscode-server/extensions/ms-python.debugpy-2025.0.1-linux-x64/.noConfigDebugAdapterEndpoints/endpoint-58a7f9bb4e53a911.txt
PYDEVD_DISABLE_FILE_VALIDATION=1
BUNDLED_DEBUGPY_PATH=/home/dobos/.vscode-server/extensions/ms-python.debugpy-2025.4.0-linux-x64/bundled/libs/debugpy
PWD=/home/dobos/project/ga_targeting
HOME=/home/dobos
CONDA_PYTHON_EXE=/datascope/slurm/miniconda3/bin/python
BROWSER=/home/dobos/.vscode-server/cli/servers/Stable-6609ac3d66f4eade5cf376d1cb76f13985724bcb/server/bin/helpers/browser.sh
VSCODE_GIT_ASKPASS_NODE=/home/dobos/.vscode-server/cli/servers/Stable-6609ac3d66f4eade5cf376d1cb76f13985724bcb/server/node
TERM_PROGRAM=vscode
SSH_CLIENT=*.*.*.* 47682 22
TERM_PROGRAM_VERSION=1.98.0
SSL_CERT_FILE=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
_CE_CONDA=
VSCODE_IPC_HOOK_CLI=/run/user/1897/vscode-ipc-b6be9198-7621-4ff0-9f9b-be5479994ff7.sock
MAIL=/var/spool/mail/dobos
VSCODE_GIT_ASKPASS_MAIN=/home/dobos/.vscode-server/cli/servers/Stable-6609ac3d66f4eade5cf376d1cb76f13985724bcb/server/extensions/git/dist/askpass-main.js
TERM=xterm-256color
SHELL=/bin/bash
CUDA_VISIBLE_DEVICES=4,5,6,7
SHLVL=6
VSCODE_GIT_IPC_HANDLE=/run/user/1897/vscode-git-ac61da60bf.sock
SSL_CERT_DIR=/etc/pki/tls/certs
LOGNAME=dobos
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1897/bus
GIT_ASKPASS=/home/dobos/.vscode-server/cli/servers/Stable-6609ac3d66f4eade5cf376d1cb76f13985724bcb/server/extensions/git/dist/askpass.sh
XDG_RUNTIME_DIR=/run/user/1897
PATH=/datascope/slurm/miniconda3/condabin:/home/dobos/.vscode-server/cli/servers/Stable-6609ac3d66f4eade5cf376d1cb76f13985724bcb/server/bin/remote-cli:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/usr/local/texlive/2023/bin/x86_64-linux:/usr/local/texlive/2023/bin/x86_64-linux:/home/dobos/.vscode-server/data/User/globalStorage/github.copilot-chat/debugCommand:/home/dobos/.vscode-server/extensions/ms-python.debugpy-2025.4.0-linux-x64/bundled/scripts/noConfigScripts:/usr/local/texlive/2023/bin/x86_64-linux
PS1=\[\]\[\]\u@\h:\w\n\[\e[0;31m\]\[\e[0m\]\$ \[\]\[\]
HISTSIZE=1000
LESSOPEN=||/usr/bin/lesspipe.sh %s
BASH_FUNC_which%%=() {  ( alias;
 eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot "$@"
}
_=/usr/bin/env

[dobos]

Could it be something to do with the new feature in vscode that detects if a program is started up in debug mode and automatically attaches to it?

[rchiodo]

Try unsetting this:

DEBUGPY_ADAPTER_ENDPOINTS

It looks like it's pointing to an old installation that no longer exists.

[dobos]

Yep, that solves it. I think the adapter should revert to the old behavior when a tcp port is explicitly defined as a command-line argument. Or at least provide some sort of error message.

[dobos]

I'm sorry but I don't think it's completed. There should be an error message displayed when the adapter can't be launched or connected to the current vscode instance.

[rchiodo]

Hmm, it's weird that there's no error message. It should have output one. This code here:

debugpy/src/debugpy/adapter/__main__.py

Line 115 in e01e6dd

with open(listener_file, "w") as f:

Creating an invalid DEBUGPY_ADAPTER_ENDPOINTS doesn't seem to output an error for me either.

[dobos]

Could it be that stderr gets lost somewhere around where debugpy launches the adapter? I could turn on verbose errors for debugpy but there is no option to pass any parameters to the adapter, even though it has the --log-stderr option. I actually modified the code to turn on logging in the adapter but I didn't see any error in the terminal.

[rchiodo]

Not sure. If you want to try debugging and submitting a fix, please feel free to do so. I believe the DEBUGPY_ADAPTER_ENDPOINTS was set by an older ms-python-debugpy extension and it's not being cleaned up, so it's likely more people are going to run into this.

[gramster]

@karthiknadig is this possibly related to the no-config debugging in the terminal?

[karthiknadig]

Please try the latest version of the debugger extension, that we shipped today (ms-python.debugpy version 2025.4.1). This should be fixed that version.

[wvanmourik-uwv]

Using version 2025.4.1 is not a fix for me.
I see the nonverbose error message: ERROR: 'DEBUGPY_ADAPTER_ENDPOINTS'

Reverting to version 2025.0.1 for now.