-
-
Notifications
You must be signed in to change notification settings - Fork 132
Description
In recent months I'd been suffering from a seemingly random problem where connecting to the debugger in VSCode from my remote gunicorn instance running in Docker would sometimes leave gunicorn completely frozen, to the point of SIGTERM having no effect, and requiring a SIGKILL to make gunicorn fully die and be restarted by supervisord.
Yesterday, I finally learned what was causing this problem. If you're running the python debug server in VSCode in "request": "attach" mode, where it listens for a remote connection, and then VSCode restarts the extension system (either automatically or via user command), the debug server silently keeps running, but it's in an effectively zombified state.
As soon as a client connects to this zombie server, the server immediately crashes without cleanly disconnecting the client, which leaves the client permanently blocked. I believe this is likely something to do with the server having nowhere to send debugging information, since it's been disconnected from VSCode, because simply attaching a socket to the appropriate port to check if it's listening does not cause the server to crash.
I think this permanently blocked state might be related to line 1478 in pydevd.py. The fact that it sets the socket timeout to None seemingly makes it so the client will never notice that the server has gone away, and it will remain blocked forever.
Given that this line has a comment saying that it's specifically a workaround for an issue in Jython, and given that Jython is seemingly no longer being developed (and is in fact still based on Python 2), perhaps line 1478 could be removed in a future version of pydevd? I'm not certain that would fix this bug, but I sure would like to see it get fixed.