You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Repeated debugpy.listen() calls should be an error #460
Python version (& distribution if applicable, e.g. Anaconda): Python 3.8.6 from Miniconda
Using VS Code or Visual Studio: No
Actual behavior
A "disconnect" request does not seem to really terminate the debug adapter as stated here. It looks like the adapter is still running in the background and that you can reconnect with "initialize" request.
Expected behavior
After a "disconnect" request, the debug adapter should be restarted the same way it was started the first time.
Steps to reproduce:
Execute the following python code in the debugee
importdebugpydebugpy.listen(5416);
Send "initiliaze" and "attach" requests.
After receiving an attach response, send a "disconnect request";
Repeat step 1. debugpy.listen never returns.
If I skip step 4 and repeat step 2 after step 3, everything works fine but this does not seem to be conformant with the DAP specification.
listen() is not supposed to be called multiple times. It starts a debug server in your process, and it's a one-off operation. The server should handle new connections (only one at a time) for as long as the process is running, though.
That said, "disconnect" request indeed doesn't terminate the adapter, and that's by design. The adapter is necessary for the debug server; and the server, once started, cannot be fully excised from the process for various reasons. The intent of the "disconnect" request, in any case, is to signal to the adapter that debugging should be stopped. It handles that accordingly, by disabling tracing (breakpoints etc) as much as Python implementation details allow.
I was surprised by this behavior because of the specification of the DAP and its difference with PTVSD, but this seems a reasonable behavior anyway. Do you think it could be worth adding a comment about this difference in this wiki page? I would be glad to do it myself, but I cannot open a PR on a wiki page.
However, I think there's a separate issue here. You mentioned that on step 4, the second call to listen() never returns at all. Normally, I would expect it to complain that the port is already open and cannot be re-used. That said, it's possible to call listen() with another port, too, and we don't try to check for that right now. A check with a clear error message here would improve this scenario a lot.
Yes, that part is definitely a bug, hence why this remains open. But I'd like to know why it didn't fail because the port is already opened - it does that when I try to repro. And if I specify a different port, then it apparently succeeds (but should fail loudly).
Activity
int19h commentedon Nov 3, 2020
listen()is not supposed to be called multiple times. It starts a debug server in your process, and it's a one-off operation. The server should handle new connections (only one at a time) for as long as the process is running, though.That said, "disconnect" request indeed doesn't terminate the adapter, and that's by design. The adapter is necessary for the debug server; and the server, once started, cannot be fully excised from the process for various reasons. The intent of the "disconnect" request, in any case, is to signal to the adapter that debugging should be stopped. It handles that accordingly, by disabling tracing (breakpoints etc) as much as Python implementation details allow.
JohanMabille commentedon Nov 3, 2020
Thanks for the quick answer!
I was surprised by this behavior because of the specification of the DAP and its difference with PTVSD, but this seems a reasonable behavior anyway. Do you think it could be worth adding a comment about this difference in this wiki page? I would be glad to do it myself, but I cannot open a PR on a wiki page.
int19h commentedon Nov 3, 2020
It should be https://github.com/microsoft/debugpy/wiki/API-Reference - I've added a clarification on
listen()there.However, I think there's a separate issue here. You mentioned that on step 4, the second call to
listen()never returns at all. Normally, I would expect it to complain that the port is already open and cannot be re-used. That said, it's possible to calllisten()with another port, too, and we don't try to check for that right now. A check with a clear error message here would improve this scenario a lot.fabioz commentedon Nov 5, 2020
Hanging in a 2nd
listen()call does actually seem like a bug to me.int19h commentedon Nov 5, 2020
Yes, that part is definitely a bug, hence why this remains open. But I'd like to know why it didn't fail because the port is already opened - it does that when I try to repro. And if I specify a different port, then it apparently succeeds (but should fail loudly).
heartacker commentedon Jun 7, 2022
#870 (comment)
maybe this is a good solution for this situation
[-]Cannot Attach again after disconnect[/-][+]Repeated debugpy.listen() calls should be an error[/+]heartacker commentedon Jun 5, 2023
anyupdates? we need this indeed