Repository navigation
Disconnecting from VSCode shouldn't exit the running program #630
Description
Your environment
ruby -v:3.1.0rdbg -v: latest master
Describe 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:
terminate current debug session via the disconnect request and immediately start a new session via the launch or attach request
For the "attach" case "restart" has no direct effect on the debug target because the debug target continues running.
We can know that disconnect request isn't meant to kill the debug target.
To Reproduce
- Start Rails server with
rdbg:$ rdbg -O -n bin/rails s - Attach to the debuggee from VSCode
- Click
Disconnector hitShift + F5for disconnecting the debug session
Expected 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 to kill!, which would exit the entire process immediately.
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:
=> Booting Puma
=> Rails 7.0.2.3 application starting in development
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
* Puma version: 5.6.2 (ruby 3.1.0-p0) ("Birdie's Version")
* Min threads: 5
* Max threads: 5
* Environment: development
* PID: 36985
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop
DEBUGGER: Connected.
DEBUGGER: Disconnected.
quit
Started GET "/" for ::1 at 2022-04-24 23:58:25 +0100
[Tracing] Starting <rails.request> transaction </>
(0.9ms) SELECT sqlite_version(*)
ActiveRecord::SchemaMigration Pluck (0.1ms) SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
Processing by WelcomeController#index as HTML
Completed 500 Internal Server Error in 55ms (ActiveRecord: 0.0ms | Allocations: 145932)
ZeroDivisionError (divided by 0):
app/controllers/welcome_controller.rb:8:in `/'
app/controllers/welcome_controller.rb:8:in `index'
#<Thread:0x000000010d042e88@DEBUGGER__::SESSION@server /Users/st0012/projects/debug/lib/debug/session.rb:144 run> terminated with exception (report_on_exception is true):
/Users/st0012/projects/debug/lib/debug/server_dap.rb:165:in `send': undefined method `write' for nil:NilClass (NoMethodError)
@sock.write "Content-Length: #{str.bytesize}\\r\\n\\r\\n#{str}"
^^^^^^
from /Users/st0012/projects/debug/lib/debug/server_dap.rb:190:in `send_event'
from /Users/st0012/projects/debug/lib/debug/server_dap.rb:399:in `event'
from /Users/st0012/projects/debug/lib/debug/session.rb:238:in `process_event'
from /Users/st0012/projects/debug/lib/debug/session.rb:194:in `session_server_main'
from /Users/st0012/projects/debug/lib/debug/session.rb:164:in `block in activate'
Exiting
Killing session flusher
Shutting down background worker
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:
DEBUGGER: Debugger can attach via UNIX domain socket (/var/folders/yg/hnbymwxd5pn7v94_clc59y6r0000gn/T/ruby-debug-sock-501/ruby-debug-st0012-37764)
Calling `DidYouMean::SPELL_CHECKERS.merge!(error_name => spell_checker)' has been deprecated. Please call `DidYouMean.correct_error(error_name, spell_checker)' instead.
=> Booting Puma
=> Rails 7.0.2.3 application starting in development
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
* Puma version: 5.6.2 (ruby 3.1.0-p0) ("Birdie's Version")
* Min threads: 5
* Max threads: 5
* Environment: development
* PID: 37764
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop
DEBUGGER: Connected.
DEBUGGER: Disconnected.
quit
^C^C^C^C^C^C # can't exit
Activity
jabamaus commentedon May 8, 2022
Latest VSCode release 1.67 has a new feature that sounds relevant:
UI for supportSuspendDebuggee and supportTerminateDebuggee
The disconnect request has two extra options that enable a client to control what happens to a debuggee when disconnecting:
suspendDebuggee indicates whether the debuggee should stay suspended after disconnection.
terminateDebuggee indicates whether the debuggee should be terminated when the debugger is disconnected.
A debug adapter can use the capabilities supportSuspendDebuggee and supportTerminateDebuggee to signal that it supports these options. When supported, a dropdown will appear next to the stop button in the debug toolbar with extra disconnect commands.
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).
ko1 commentedon Jul 6, 2022
Thank you.
Maybe all breakpoints should be removed at disconnect.
Maybe there are some bugs around here, so I check it today.
check `in_subsession?` on disconnect request
check `in_subsession?` on disconnect request
ko1 commentedon Jul 8, 2022
#690 may solve this issue.
I repeated with my small script and
rails s, but can not reproduce.Around this kind of timing issue can be there so please file another issue if you find.
st0012 commentedon Jul 8, 2022
This still happens when the program is suspended
Then the program exists.
If it's just:
The debuggee doesn't exit.
check `in_subsession?` on disconnect request
ko1 commentedon Jul 9, 2022
I couldn't reproduce with my small Rails project.
debuggerinto pages_controller.rb#indexrdbg -nO -c -- bin/rails sI think there are more conditions to reproduce. Now I can not debug it more, so if you find more, please make another issue.
check `in_subsession?` on disconnect request