-
Notifications
You must be signed in to change notification settings - Fork 130
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
Disconnecting from VSCode shouldn't exit the running program #630
Comments
Latest VSCode release 1.67 has a new feature that sounds relevant: UI for supportSuspendDebuggee and supportTerminateDebuggee suspendDebuggee indicates whether the debuggee should stay suspended after disconnection. For example, in a "launch"-type debug session, for a debug adapter that supports both capabilities, the default toolbar button will be the normal Stop button, but the dropdown will include Disconnect (terminateDebuggee: false) and Disconnect and Suspend (terminateDebuggee: false, suspendDebuggee: true). |
Thank you. Maybe all breakpoints should be removed at disconnect. |
This message can be received while in the subsession or not (running debuggee program) and it should change the handling. Also `UI_DAP#event` can be called after closing the socket so so `send` should check `@sock` is available or not. fix #630
This message can be received while in the subsession or not (running debuggee program) and it should change the handling. Also `UI_DAP#event` can be called after closing the socket so so `send` should check `@sock` is available or not. fix #630
#690 may solve this issue. |
This still happens when the program is suspended
Then the program exists. If it's just:
The debuggee doesn't exit. |
This message can be received while in the subsession or not (running debuggee program) and it should change the handling. Also `UI_DAP#event` can be called after closing the socket so so `send` should check `@sock` is available or not. fix ruby#630
I couldn't reproduce with my small Rails project.
I think there are more conditions to reproduce. Now I can not debug it more, so if you find more, please make another issue. |
This message can be received while in the subsession or not (running debuggee program) and it should change the handling. Also `UI_DAP#event` can be called after closing the socket so so `send` should check `@sock` is available or not. fix ruby#630
Your environment
ruby -v
:3.1.0
rdbg -v
: latest masterDescribe the bug
When hitting "Disconnect (Shift + F5)", the attached program (e.g. Rails server) will be killed along with the debug session.
Based on the DAP spec maintainer's comment:
We can know that disconnect request isn't meant to kill the debug target.
To Reproduce
rdbg
:$ rdbg -O -n bin/rails s
Disconnect
or hitShift + F5
for disconnecting the debug sessionExpected behavior
The debug session ends but not the Rails server.
Additional context
The direct cause of process exiting is because DAP's
readline
input falls back tokill!
, which would exit the entire process immediately.debug/lib/debug/server_dap.rb
Line 371 in 0319744
I think changing it to
quit!
can avoid the immediate kill. But the DAP server's left-over may still cause error to the program:In this case, it's probably because a
CatchBreakpoint
added by the debugger was triggered after the disconnection. And the debugger still tried to send a message to the client through DAP server, which's@sock
was already cleared from the disconnection.I also noticed that after disconnecting the debuggee, the interrupt signal doesn't work anymore:
The text was updated successfully, but these errors were encountered: