debug icon indicating copy to clipboard operation
debug copied to clipboard

Feature request: Stop debugger until first client connects

Open jvilk-stripe opened this issue 3 years ago • 4 comments

Your proposal

Make it possible for the debugger to pause the program until the first client connects:

require "debug/open_wait_for_client"
# Program is now paused until the first debugger client connects

Once the first client connects, the program can proceed.

Additional context

We are working to integrate debug.rb into Stripe's Ruby test runner. The test runner needs to start the server and wait for VS Code to connect before running the tests.

debug/open does not work for this use case. debug/open pauses the program when the debugger starts, but does not resume the program after VS Code connects. Instead, VS Code reports the program as paused on a breakpoint in our test runner code. The user then has to hit "resume" to run their tests and hit the breakpoints that they actually set.

jvilk-stripe avatar Aug 26 '22 21:08 jvilk-stripe

In the use case you described, do you always have breakpoints set in your tests?

If the answer is yes, then using debug/open_nonstop will skip the initial stop, but will wait for attaching once it hits a breakpoint. If the answer is no, then I don't get the need to connect to the VSCode since the program will just finish.

st0012 avatar Aug 31 '22 10:08 st0012

In the use case you described, do you always have breakpoints set in your tests?

Yes -- in VS Code.

If the answer is yes, then using debug/open_nonstop will skip the initial stop, but will wait for attaching once it hits a breakpoint.

The problem is that the breakpoints get set just after VS Code attaches. VS Code is doing the breakpoint setting.

jvilk-stripe avatar Aug 31 '22 16:08 jvilk-stripe

Hi, I understand your request that

  • On the VSCode, you setup breakpoints on the editor. You want to stop on that.
  • You don't want to launch tests from VSCode (F5 key to launch debug process) maybe because there are some reasons.
  • You want to invoke your test runner in your terminal or somewhere you want.
  • You want to attach VScode just before your tests run.
  • You don't want to stop the program at attaching timing, but you want to stop at breakpoints you setup on VSCode.

Right?

Can I ask something?

  • There are some options to solve this issue.
      1. add an option to #open method like #747
      1. add an option to VSCode launch.json (nonstop on attach)
      1. add an option to load breakpoints setup by VSCode on loading timing of debug.gem

Maybe (c) is most easy way for you because you don't need to launch VSCode and attach to the debuggee if no breakpoints are reached. When it stops at breakpoint, you can attach to the debuggee (test process) at that time.

In fact, vscode-rdbg supports to export breakpoints.

image

But not supported by debug.gem to load it because of some security concerns.

I want to ask which is the best. Honestly speaking on_client_connected: option (1) is too tricky for me.

ko1 avatar Sep 16 '22 07:09 ko1

@ko1: yes, your description of our requirements is correct. Also, I agree that my proposed solution is hacky, and doesn't follow any of the patterns that the debug gem already uses, so I'd be happy to see another solution.

Regarding your options:

a. is https://github.com/ruby/debug/pull/747 (which we agree is not the best) b. I don't understand how this would be implemented on the gem, exactly c. I assume you mean that users would set a new ENV variable/send a new option when starting the debugger, so the gem would know to try to load the breakpoints on startup. This looks like the most elegant solution, as long as it respects things like local_fs_map

marianosimone avatar Sep 20 '22 00:09 marianosimone

@ko1 can you say more about:

But not supported by debug.gem to load it because of some security concerns.

This issue is the last thing that is preventing Stripe from using the gem without forking it, and we'd love to help move the feature along :)

marianosimone avatar Nov 02 '22 19:11 marianosimone

https://github.com/ruby/debug/pull/792#issuecomment-1302536659 adding (b). Could you check it?

ko1 avatar Nov 03 '22 18:11 ko1

For (c) please try:

  • enable "(experimental) Save breakpoints information to '.rdbg.breakpoints' for rdbg command" option
  • set breakpoints on VSCode
  • run rdbg -nO with -x .rdbg.breakpoints like rdbg -x .rdbg.breakpoints -nO sample.rb

and it debuggee process will stop at the breakpoint and you can attach from VSCode.

https://user-images.githubusercontent.com/9558/199837938-2ae9d8de-de45-47c8-a409-9d60ecb6a0c1.mp4

Now VSCode extension has an issue (breakpoint line is wrong with -1 because of 0-origin and 1-origin issue) but it will be fixed soon.

ko1 avatar Nov 03 '22 21:11 ko1