Skip to content
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

Closed
st0012 opened this issue Apr 24, 2022 · 5 comments · Fixed by #690
Closed

Disconnecting from VSCode shouldn't exit the running program #630

st0012 opened this issue Apr 24, 2022 · 5 comments · Fixed by #690
Milestone

Comments

@st0012
Copy link
Member

st0012 commented Apr 24, 2022

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.

@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
Copy link

jabamaus commented 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 ko1 added this to the v1.6.0 milestone May 17, 2022
@ko1
Copy link
Collaborator

ko1 commented 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.

ko1 added a commit that referenced this issue Jul 8, 2022
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
@ko1 ko1 closed this as completed in #690 Jul 8, 2022
ko1 added a commit that referenced this issue Jul 8, 2022
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
@ko1
Copy link
Collaborator

ko1 commented 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
Copy link
Member Author

st0012 commented Jul 8, 2022

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.

st0012 pushed a commit to ruby-tooling/ruby-debugger that referenced this issue Jul 8, 2022
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
@ko1 ko1 reopened this Jul 9, 2022
@ko1
Copy link
Collaborator

ko1 commented Jul 9, 2022

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.

@ko1 ko1 closed this as completed Jul 9, 2022
st0012 pushed a commit to ruby-tooling/ruby-debugger that referenced this issue Jul 10, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants