Disconnecting from VSCode shouldn't exit the running program

[st0012]

Your environment

• ruby -v: 3.1.0
• rdbg -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

1. Start Rails server with rdbg: $ rdbg -O -n bin/rails s
2. Attach to the debuggee from VSCode
3. Click Disconnect or hit Shift + F5 for 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.

debug/lib/debug/server_dap.rb

Line 371 in 0319744

@q_msg.pop || 'kill!'

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

[jabamaus]

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]

Thank you.

Maybe all breakpoints should be removed at disconnect.
Maybe there are some bugs around here, so I check it today.

[ko1]

#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]

This still happens when the program is suspended

1. Start Rails server with rdbg and connect to VSCode
2. Trigger a breakpoint
3. Disconnect from the VSCode

Then the program exists.

If it's just:

1. Start Rails server with rdbg and connect to VSCode
2. Disconnect from the VSCode

The debuggee doesn't exit.

[ko1]

I couldn't reproduce with my small Rails project.

• rails new
• rails scaffold pages && db:migrate
• insert debugger into pages_controller.rb#index
• run rdbg -nO -c -- bin/rails s
• attach from VSCode
• brows localhost:3000/pages
• stop at breakpoint
• disconnect from VSCode
• browser shows pages successfully
• VSCode can attach again

I think there are more conditions to reproduce. Now I can not debug it more, so if you find more, please make another issue.