Re-attaching continuously creates 'accept_worker' threads in debugpy

[rchiodo]

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

Environment data

• debugpy version: 1.62
• OS and version: Windows 10
• Python version (& distribution if applicable, e.g. Anaconda): 3.10
• Using VS Code or Visual Studio: VS code

Steps to reproduce:

1. Set the new 'DEBUGPY_TRACE_DEBUGPY' flag. This allows the debugger to see debugpy threads.
2. Start VS code (so that it uses this environment variable) and open a notebook
3. Debug a cell
4. Finish debugging the cell (if it hasn't already)
5. Start another VS code to debug the first
6. Attach to the adapter process
7. Check the list of threads. It should show something like so:

8. Debug the same cell again
9. Check list of threads in other VS code

10. Repeat

The 'accept_worker' thread list keeps growing.

Not sure if this is problem in the debug commands sent from VS code (maybe it never actually detaches?) or if debugpy is not cleaning things up on disconnect.

[int19h]

There should be an entry in the adapter log for each one of those, saying "Listening for incoming ... connections" - the triple dots would indicate the source.

[rchiodo]

It shows a different port on every debug cell request:

Debug Cell first time:

         Listening for incoming Server connections on 127.0.0.1:53754...

Debug Cell second time:

         Listening for incoming Server connections on 127.0.0.1:53758...

Debug Cell third time:

         Listening for incoming Server connections on 127.0.0.1:53795...

[rchiodo]

The jupyter code is starting a new attach on every debug cell:

https://github.com/microsoft/vscode-jupyter/blob/8b098c2e42e4dc4db7d0ffc0b0a1c87f740da582/src/notebooks/debugger/debuggingManager.ts#L271

[int19h]

Ah, I see now - it's because servers.serve() is called in the adapter every time "launch" or "attach" is handled. It doesn't affect functionality otherwise so far as I can tell, because it always directs new servers to the most recent port it opened, so those old threads just idle, wasting memory but nothing else.

Now, it does need to do on every request, because "debugAdapterHost" specifies the host used for adapter/server communications (there can be a network boundary between them in Docker scenarios), and can be different from request to request, so the server listener must be recreated anew. So the proper fix here is to call servers.stop_serving() first to clean up the old stuff.