Support for force quitting the adapter process during remote attach

[Layty]

my system is aarch64, ubunut core 20.04.

I have
1. build attach_linux_amd64.so
2. fix gdb as #1413 , without "--batch"
then
python3 -m debugpy --listen 0.0.0.0:5678 --pid 6410

then in gdb cmd input continute, and vscode works ok.

but next time, I kill gdb and debugpy , I can not run python3 -m debugpy --listen 0.0.0.0:5678 --pid 6410 , it tells me listen is already.

so how can I disable listen and reattach the pid .

[Layty]

debugpy.listen() has already been called on this process raise in

@_starts_debugging
def listen(address, settrace_kwargs, in_process_debug_adapter=False):
    # Errors below are logged with level="info", because the caller might be catching
    # and handling exceptions, and we don't want to spam their stderr unnecessarily.

    if listen.called:
        # Multiple calls to listen() cause the debuggee to hang
        raise RuntimeError("debugpy.listen() has already been called on this process")

[rchiodo]

You shouldn't have to run debugpy a second time. Just reattach to the same port in VS code. The debugpy adapter should still be running. Or you could kill all the debugpy processes that are running.

I believe what's happening in your scenario is you're starting debugpy to attach to the pid specified, killing the pid, but not killing the other processes started by debugpy.

[Layty]

when I use attach normaly device is remote in others, I will use ssh to exec debugpy , and in gdb input "continue" to run gdb.

but when I input ctrl+c in gdb , or if the ssh session is exit , debugpy and gdb is also exit ,

so I can not aatach it next time. so how should I do ?

I means if debugpy is accident exit, how shoud I do to repair it .

maybe use nohup ? but it means gdb is always run .

[rchiodo]

I'm not sure what you're using gdb for? Are you native debugging this process as well?

The way to repair debugpy is to kill all the python processes that debugpy starts on the remote machine.

[Layty]

I have to fix debugpy without "--batch", #1413 so when I run debugpy it will run into gdb

so when run debugpy, I have to input continute then vscode can connect adapter .

I have kill debugpy and adapter , but it not works.

python3 -m debugpy --listen 0.0.0.0:5678 --pid 384951
Using /usr/local/lib/python3.8/dist-packages/debugpy/_vendored/pydevd/pydevd_attach_to_process/attach_linux_amd64.so in arch: aarch64.
PYDEVD_GDB_SCAN_SHARED_LIBRARIES not set (scanning all libraries for needed symbols).
Running: gdb --nw --nh --nx --pid 384951 --eval-command='set scheduler-locking off' --eval-command='set architecture auto' --eval-command='call (void*)dlopen("/usr/local/lib/python3.8/dist-packages/debugpy/_vendored/pydevd/pydevd_attach_to_process/attach_linux_amd64.so", 2)' --eval-command='sharedlibrary attach_linux_amd64' --eval-command='call (int)DoAttach(0, "import codecs;import json;import sys;decode = lambda s: codecs.utf_8_decode(bytearray(s))[0] if s is not None else None;script_dir = decode([47, 117, 115, 114, 47, 108, 111, 99, 97, 108, 47, 108, 105, 98, 47, 112, 121, 116, 104, 111, 110, 51, 46, 56, 47, 100, 105, 115, 116, 45, 112, 97, 99, 107, 97, 103, 101, 115, 47, 100, 101, 98, 117, 103, 112, 121, 47, 115, 101, 114, 118, 101, 114]);setup = json.loads(decode([123, 34, 109, 111, 100, 101, 34, 58, 32, 34, 108, 105, 115, 116, 101, 110, 34, 44, 32, 34, 97, 100, 100, 114, 101, 115, 115, 34, 58, 32, 91, 34, 48, 46, 48, 46, 48, 46, 48, 34, 44, 32, 53, 54, 55, 56, 93, 44, 32, 34, 119, 97, 105, 116, 95, 102, 111, 114, 95, 99, 108, 105, 101, 110, 116, 34, 58, 32, 102, 97, 108, 115, 101, 44, 32, 34, 108, 111, 103, 95, 116, 111, 34, 58, 32, 110, 117, 108, 108, 44, 32, 34, 97, 100, 97, 112, 116, 101, 114, 95, 97, 99, 99, 101, 115, 115, 95, 116, 111, 107, 101, 110, 34, 58, 32, 110, 117, 108, 108, 125]));sys.path.insert(0, script_dir);import attach_pid_injected;del sys.path[0];attach_pid_injected.attach(setup);", 0)'
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.2) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 384951
Reading symbols from /usr/bin/python3.8...
(No debugging symbols found in /usr/bin/python3.8)
Reading symbols from /lib/aarch64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/db/c64109854269eb569f7a496dc85cb1a559ec87.debug...
Reading symbols from /lib/aarch64-linux-gnu/libpthread.so.0...
Reading symbols from /usr/lib/debug/.build-id/77/ec3f4eac97eec4597dc9f139763db3fa09b3da.debug...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Reading symbols from /lib/aarch64-linux-gnu/libdl.so.2...
Reading symbols from /usr/lib/debug/.build-id/38/4b6e36e7568df77ec89cf36531ea97c592f814.debug...
Reading symbols from /lib/aarch64-linux-gnu/libutil.so.1...
Reading symbols from /usr/lib/debug/.build-id/6c/89192da4b6d0b86cd3d3870e92735ef3db1512.debug...
Reading symbols from /lib/aarch64-linux-gnu/libm.so.6...
Reading symbols from /usr/lib/debug/.build-id/e7/50473ad00acdf0e8eeb674539e5a8bc12ed865.debug...
Reading symbols from /lib/aarch64-linux-gnu/libexpat.so.1...
(No debugging symbols found in /lib/aarch64-linux-gnu/libexpat.so.1)
Reading symbols from /lib/aarch64-linux-gnu/libz.so.1...
(No debugging symbols found in /lib/aarch64-linux-gnu/libz.so.1)
Reading symbols from /lib/ld-linux-aarch64.so.1...
Reading symbols from /usr/lib/debug/.build-id/69/27993b5ea4304ff398d99d28f36476a848ce21.debug...
0x0000ffff8a22d728 in __GI___select (nfds=0, readfds=0x0, writefds=0x0, exceptfds=0x0, timeout=0xffffef9b3aa0) at ../sysdeps/unix/sysv/linux/select.c:53
53      ../sysdeps/unix/sysv/linux/select.c: No such file or directory.
The target architecture is set automatically (currently aarch64)
$1 = (void *) 0x1b21a730
Symbols already loaded for /usr/local/lib/python3.8/dist-packages/debugpy/_vendored/pydevd/pydevd_attach_to_process/attach_linux_amd64.so
[Detaching after fork from child process 385654]
[Detaching after fork from child process 385657]
[New Thread 0xffff886441e0 (LWP 385679)]
[New Thread 0xffff87e431e0 (LWP 385680)]
[New Thread 0xffff876421e0 (LWP 385682)]
[New Thread 0xffff86e411e0 (LWP 385683)]
[New Thread 0xffff866401e0 (LWP 385684)]
[Thread 0xffff866401e0 (LWP 385684) exited]
[New Thread 0xffff866401e0 (LWP 385693)]
[Thread 0xffff866401e0 (LWP 385693) exited]
[New Thread 0xffff866401e0 (LWP 385696)]
[Thread 0xffff866401e0 (LWP 385696) exited]
[New Thread 0xffff866401e0 (LWP 385697)]
[Thread 0xffff866401e0 (LWP 385697) exited]
[New Thread 0xffff866401e0 (LWP 385698)]
[Thread 0xffff866401e0 (LWP 385698) exited]
[New Thread 0xffff866401e0 (LWP 385699)]
[Thread 0xffff866401e0 (LWP 385699) exited]
[New Thread 0xffff866401e0 (LWP 385702)]
[Thread 0xffff866401e0 (LWP 385702) exited]
$2 = 0
(gdb) c
Continuing.

[rchiodo]

Oh, so you rebuilt the attach .so file so that it launches gdb in batch mode. There should be other processes started by debugpy on that machine though. Those other processes are the ones that are listening. You need to kill those.

[Layty]

I think there is no other debugpy , I only write a demo abc.py, then run debugpy , then kill debugpy . how can I find other debugpy , I have use ps aux | grep python to find and ps aux | grep ada

[rchiodo]

For me (on windows), I have three processes.

1. The python process for the program I started (your python abc.py)
2. The python process that does the injection (the one started by python -m debugpy --listen 5678 --pid <blah>)
3. An adapter process that sits around waiting for the connection from the debugger

All 3 of those processes may have to go away in order for you to reconnect again. If your original process sticks around, you should be able to just debug attach again. The debugger is already injected into that process so you can detach/reattach as much as you want.

You second process (the one running gdb) may be surviving? Not sure what running in batch mode does to the shutdown of the injection process. For me (on windows), the 2nd process exits as soon as the injection is complete. Then the number 1 process has debugpy inside of it and it's talking to the number 3 process. Stopping debugging in VS code won't cause those to go away though. The adapter process (number 3) will stick around until the original process (number 1) is gone.

That adapter process is supposed to allow reattach.

Here's what the command line looks for me:

[Layty]

oh, I know. I found adapter ppid is 1 , so it will not exit if ssh is close .

the problem is I close it by myself, then I can not run debugpy next time.

so how abc.py can close listen attach so the debugpy can run twice .

when I finish debug, I think I would close debugpy and adapter . then then abc.py must to restart to run so that can be attach next time ?

so I think it is a new future ?

[rchiodo]

I think what you're asking for is to somehow force close the number 3 process as it's not shutting down even after the number 1 process dies?

Transferring to a discussion item as an enhancement request. Something to force quit the adapter even though it thinks the attached process is still alive.