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

Feature request: Stop debugger until first client connects #739

Closed
jvilk-stripe opened this issue Aug 26, 2022 · 7 comments · Fixed by #792
Closed

Feature request: Stop debugger until first client connects #739

jvilk-stripe opened this issue Aug 26, 2022 · 7 comments · Fixed by #792
Labels
enhancement New feature or request

Comments

@jvilk-stripe
Copy link

jvilk-stripe commented Aug 26, 2022

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.

@st0012
Copy link
Member

st0012 commented Aug 31, 2022

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.

@jvilk-stripe
Copy link
Author

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.

@ko1
Copy link
Collaborator

ko1 commented Sep 16, 2022

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?

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 ko1 added the enhancement New feature or request label Sep 16, 2022
@ko1 ko1 added this to the v1.7.0 milestone Sep 16, 2022
@marianosimone
Copy link
Contributor

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

@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 :)

ko1 added a commit that referenced this issue Nov 3, 2022
attach configuration in launch.json file `"nonstop": true` option
is supported. If nonstop is true, do not pause on attach timing.

fix #739
@ko1
Copy link
Collaborator

ko1 commented Nov 3, 2022

#792 (comment) adding (b).
Could you check it?

@ko1 ko1 closed this as completed in #792 Nov 3, 2022
ko1 added a commit that referenced this issue Nov 3, 2022
attach configuration in launch.json file `"nonstop": true` option
is supported. If nonstop is true, do not pause on attach timing.

fix #739
@ko1
Copy link
Collaborator

ko1 commented Nov 3, 2022

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.

Extension.Development.Host.sample.rb.-.simple_sample.WSL_.Ubuntu-20.04.-.Visual.Studio.Code.2022-11-04.06-25-42.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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

Successfully merging a pull request may close this issue.

4 participants