Launching VSCode debugpy takes significantly longer to attach to process after update to 1.6.2

[mwpark2014-d]

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

Environment data

• debugpy version: 1.6.2
• OS and version: Ubuntu 18.04.6 LTS
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.7.5
• Using VS Code or Visual Studio: VS Code

Actual behavior

Attaching the debugger takes significantly longer (22 minutes) to start up my app.

Expected behavior

Around 17 seconds build time with the same code.

Steps to reproduce:

1. Update vscode-python version from 8.1 to 10.0, which updates debugpy to 1.6.2
2. Run and debug my app (gunicorn running flask) through VS code. launch.json settings and app code are the same
3. App takes significantly longer to build imported packages, specifically python-jose version 3.0.1

Can provide more info upon request

[fabioz]

One change in the attach is related to the shared libraries scanned at attach time with gdb which is probably the culprit here.

Previously we specified the libraries needed to get dlopen to work, but depending on the Linux distribution it'd fail from time to time, so, it was decided not to specify those before and just let it analyze all shared libraries (but that can make the attach much slower depending on your setup -- on some cases it's barely noticeable but in some it really can be much slower -- still, I hadn't seen a report for a 22 minute attach up until now... I guess we should have a way of notifying after some timeout how the user can specify the shared libraries to scan).

Anyways, the way to fix this for you is setting an environment variable saying which are the shared libraries that must be scanned.

You can do this by setting the following environment variable:

PYDEVD_GDB_SCAN_SHARED_LIBRARIES=libdl, libltdl, libc, libfreebl3

Please let me know if doing that fixes it for you.

[fabioz]

Actually, rereading I'm not sure this is actually it... does this happen in an attach to situation or just running your app (and the issue is that running your use case is slower)?

If it's the case that it's just slower to run, do you think you could provide some code to showcase what's slower in the current version vs the previous version?

[mwpark2014-d]

Thanks for the speedy response. I believe this is an attach to situation. I have a launch.json file that launches ~/.virtualenvs/my_app/bin/gunicorn.

Here is the output when running the configuration:
/usr/bin/env /home/.virtualenvs/my_app/bin/python /home/discord/.vscode-server/extensions/ms-python.python-2022.10.0/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher 38127 -- ~/.virtualenvs/my_app/bin/gunicorn --worker-class=gevent --bind=0.0.0.0:5004 --reload --timeout=0 my_app:create_app\(\)

The slowdown is before the app starts executing code. If I set a breakpoint, I can see that it stalls when importingpython-jose, which depends on a bunch of auth libraries.

I tried setting PYDEVD_GDB_SCAN_SHARED_LIBRARIES=libdl, libltdl, libc, libfreebl3 as an env variable in my launch.json file, but that didn't seem to work

[fabioz]

If you set PYDEVD_GDB_SCAN_SHARED_LIBRARIES=libdl, libltdl, libc, libfreebl3 in your shell and then start VSCode from that shell so that it's inherited, does it work?

[mwpark2014-d]

I tried export PYDEVD_GDB_SCAN_SHARED_LIBRARIES="libdl, libltdl, libc, libfreebl3" in my python debug console but that didn't work

[fabioz]

I tried export PYDEVD_GDB_SCAN_SHARED_LIBRARIES="libdl, libltdl, libc, libfreebl3" in my python debug console but that didn't work

You actually need to do that in the shell that starts VSCode itself (if you do that, does it work?)

[fabioz]

I was thinking about how to deal with this... ideally we'd be able to show to the user a message saying that the attach is taking longer than expected after some time and notify about customizing the PYDEVD_GDB_SCAN_SHARED_LIBRARIES, the problem is that in VSCode the output that's given by the debugger during the attach isn't shown (or I searched in the wrong place...).

@int19h do you think it'd be possible for vscode-python to show the output that's given from the debugger during the attach?

If the output is shown in vscode-python, then we could make it clearer for users on how to make it faster.

Also, the debugger is in kind of a crossroad here. Either it goes to the always works mode but can be slow or it goes to the it works most times, but it may fail in an untested platform... I'm not sure what's better.

[int19h]

We don't propagate events from the server until after we send the "attach" response.

debugpy/src/debugpy/adapter/clients.py

Lines 579 to 582 in 646d921

	finally:
	if self.start_request.response is None:
	self.start_request.respond({})
	self._propagate_deferred_events()

We could special-case "output" by propagating them as soon as client connects. That would change their order wrt all other events that might happen during initialization, but I think it should be safe for output.

[fabioz]

In this particular case, we are pre-connection.

i.e.: we want to show the output of the process spawned for the attach (which is currently put in the logs at: https://github.com/microsoft/debugpy/blob/v1.6.3/src/debugpy/adapter/servers.py#L555).

[int19h]

Ah, I see now. That method is called from the "attach" request handler, so there's a client connection to which output could be propagated. However, we probably also don't want to propagate everything - IIRC, some of it is diagnostic, and we really just want the errors/warnings. Maybe use stdout and stderr to separate these? Currently this only captures stdout, but it really should capture both.

[fabioz]

Yes, you're right that some of it may be too much info... I think separating stdout/stderr can make sense to show only errors -- right now it prints everything to stdout.

Although I must say that if there's some kind of progress UI maybe it'd be nice to show the stdout too so that the user can get a sense of what's happening -- and if an error actually happens showing the stdout can also help in tracking down what may be the actual problem.

[fabioz]

I'll take a look at sending those as output events.