-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Occasional missing response to "configurationDone" #314
Comments
Sample failure from a test run:
|
I'm taking a look at this, and now I'm making sure that the message is being sent in the socket before the process is shutdown, but the problem is that this is not enough as after writing to the socket the kernel may still take some time to actually send the message and it's still possible that the process finishes before the message is sent. From what I read, the only way to guarantee it would be doing an additional acknowledgement (this would also fix microsoft/ptvsd#1699)... this can be implicit (with careful managing of the socket lifetime shutting down just the write on the server, acknowledging that on the client and then having the client acknowledge it and close the write too, which would then be acknowledged on the server) or by explicitly passing some message (so, the server would send an message to be acknowledged by the client and when the server receives that confirmation it can exit knowing everything is sent). Between those I'm now more inclined to have an explicit message about the shutdown, so, We can either reuse a message (such as the @int19h @karthiknadig what do you think? |
Strictly speaking, DAP already says that a debug adapter shouldn't disconnect when debuggee terminates - it should report "terminated" event when debugging is over, but it's client's prerogative to decide when to close the connection. This is already how it works in practice between the IDE and the new adapter. What if we also make pydevd work in the same manner - i.e. block process shutdown until the client closes connection from its end? |
So, in this case the idea would be reporting Note that at this point it'd be either blocked at |
Yep. |
This is still happening - here's pydevd log from a recent Python 3.5 run:
Note the part about "timed out waiting for writer to be empty". On the adapter side, it simply never receives the response:
The timestamps correspond to the 500ms timeout for the writer thread. So it looks like the writer thread is blocked on something. However, looking at the code, I don't see any obvious way as to how it could end up being blocked before draining the queue. |
Dup of microsoft/ptvsd#1942 |
This is still happening in test runs. @fabioz, given the long history of this issue and all the attempts to remedy it so far, would you say that this just has to be gracefully handled by the adapter? i.e. that if it sends "configurationDone", and instead of a response, the server just disconnects, it should assume that it ran to completion, and not report it as an error to the client? |
Yes, I think that's a good idea. |
Don't treat missing response as error, but gracefully finalize the debug session instead.
The fix wasn't complete, and this still happens in test runs. |
Actually handle missing response to "configurationDone". Fix comment for handling missing responses to "launch" and "attach".
Sometimes, when receiving "configurationDone", and starting to execute user code, if the script exits almost immediately, the adapter closes the connection before the response to "configurationDone" is actually delivered to the client.
I've only seen it on CI Linux and macOS runs, and it's very rare, so it's hard to diagnose. But I suspect that this is another manifestation of pydevd messaging being asynchronous (#1699) - basically, if the process exits too fast, pydevd simply doesn't deliver the response, or delivers a partial response. The adapter then treats it as a failed response from the server, and in turn responds to IDE's "configurationDone" with failure "Server-1 disconnected unexpectedly".
Part of the problem may be that
on_configurationdone_request()
inpydevd_process_net_command_json.py
invokesapi.run()
before sending the response. Perhaps that needs to be re-ordered?The text was updated successfully, but these errors were encountered: