Debug not working

[alexevanczuk]

Operating System

13.2.1 (22D68)

Ruby version

3.2.0

Project has a bundle

• [X] Has bundle

Ruby version manager being used

rbenv

Description

Hi! I'm excited to try to use VSCode's breakpoints to debug my tests and application code instead of binding.pry. It will be a game changer when I can get it working!

I followed the instructions in the README to create my launch.json, which looks like this:

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "type": "ruby_lsp",
      "name": "Debug",
      "request": "launch",
      "program": "ruby ${file}"
    },
    {
      "type": "ruby_lsp",
      "request": "launch",
      "name": "Debug test file",
      "program": "ruby -Itest ${relativeFile}"
    },
    {
      "type": "ruby_lsp",
      "request": "attach",
      "name": "Attach to existing server"
    }
  ]
}

Note that I'm working in a rails app that uses rspec.

I then try to enter the debugger in one of two ways:

1. I open a test file and click "debug" or and "debug test file" and click the green triangle. All that happens is that it shows up under "call stack" as running, but otherwise I don't see anything to indicate I'm running a test or have entered a debug session. When I click the red square to stop it, nothing happens and it's not removed from the "call stack" section.

2. I tried clicking "debug" from https://github.com/st0012/ruby-lsp-rspec (cc @st0012). Similar to before – nothing happens.

Please let me know the recommended approach to move forward here. Also happy to provide any other information that will be helpful for debugging. Note that otherwise, my ruby-lsp is working exactly as expected. Thanks for working on and releasing such a great toolchain for the ruby community!

[vinistock]

Hello! Thank you for the bug report and the kind words about the project.

There's a chance that the two issues aren't related, so I'd like to start by understanding the first one. It's been a while since I last used RSpec, but I think our default launch configuration isn't going to work. It's designed to take advantage of Minitest and Test Unit's autorun behaviour.

You probably need to change the launch configurations into something like this

{
  "version": "0.2.0",
  "configurations": [
    // ...
    {
      "type": "ruby_lsp",
      "request": "launch",
      "name": "Debug spec file",
      "program": "bundle exec rspec ${relativeFile}"
    },
    // ...
  ]
}

You may also be able to use line numbers to run the test currently under the cursor, since RSpec supports that.

{
  "version": "0.2.0",
  "configurations": [
    // ...
    {
      "type": "ruby_lsp",
      "request": "launch",
      "name": "Debug spec example",
      "program": "bundle exec rspec ${relativeFile}:${lineNumber}"
    },
    // ...
  ]
}

Please, let us know if this makes the launch debugging work. This is the one through the Run and Debug panel.

[alexevanczuk]

Thanks @vinistock for the response.

It doesn't appear that this is making things work unfortunately. It doesn't look like anything happens (it's just hanging), although when I try to start a new debug session through the status bar button I get:

'Debug spec file' is already running. Do you want to start another instance?

Let me know what ya think! Thank you!

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months

[alexevanczuk]

Hey @vinistock

Let me know if you're still able to help me get this working! If I can get vscode breakpoints working in my test suite that would be a game changer and I can definitely write up some docs/blog post helping other folks get set up too!

[vinistock]

Definitely! Sorry for the delay.

I can't really reproduce the issue you're having, so would you be willing to to debug the extension so that we can understand exactly what's happening?

We can add a breakpoint on this line and verify if we're receiving the expected messages back from the debug process. I suspect something might be failing there.

Also, there are some new logs we added to VS Code's Output tab. Those might be helpful for us to understand how the debug process is being launched.

To test this out locally, you need to

• Clone this repo
• Make sure dependencies are installed (yarn install)
• Click F5 to run the extension in development mode (alternatively, go to run and debug and just click the launch button)
• This will open a second VS Code window, where the development version of the extension is running
• Make sure the project you want to debug is opened on that second window. You can just open the folder as you'd normally do it in any other VS Code window
• In the main VS Code window (the one with the extension code), put the breakpoint in the line I mentioned
• In the second window, try to launch the debugger. You should stop at the breakpoint
• From this point on, we need to understand why the debug server is not connecting. Is it printing something we don't expect? Is it not printing to stderr at all?

[alexevanczuk]

Hey @vinistock thanks for your help!

I followed these instructions and here's what I observed:

• In the output tab for ruby lsp, I get this:

  
  2023-11-27 15:10:43.263 [info] Checking if asdf is available on the path with command: /bin/zsh -ic 'asdf --version'
  2023-11-27 15:10:43.263 [info] Checking if chruby is available on the path with command: /bin/zsh -ic 'chruby --version'
  2023-11-27 15:10:43.306 [info] Checking if rbenv is available on the path with command: /bin/zsh -ic 'rbenv --version'
  2023-11-27 15:10:43.391 [info] Discovered version manager rbenv
  2023-11-27 15:10:43.391 [info] Trying to activate Ruby environment with command: /bin/zsh -ic 'rbenv exec ruby -rjson -e "STDERR.printf(%{RUBY_ENV_ACTIVATE%sRUBY_ENV_ACTIVATE}, JSON.dump({ env: ENV.to_h, ruby_version: RUBY_VERSION, yjit: defined?(RubyVM::YJIT) }))"' inside directory: /Users/alexevanczuk/workspace/my_repo
  2023-11-27 15:10:44.030 [info] Ruby LSP> Skipping custom bundle setup since both `ruby-lsp` and `debug` are already in /Users/alexevanczuk/workspace/my_repo/Gemfile
  Ruby LSP> Running bundle install for the custom bundle. This may take a while...
  Ruby LSP> Command: (bundle check || bundle install) 1>&2

2023-11-27 15:10:44.199 [info] The Gemfile's dependencies are satisfied

2023-11-27 15:10:45.269 [info] Starting Ruby LSP...

2023-11-27 15:10:45.288 [info] Ruby LSP is ready

2023-11-27 15:11:16.266 [info] Spawning debugger in directory /Users/alexevanczuk/workspace/my_repo 2023-11-27 15:11:16.267 [info] Command bundle exec rdbg --open --command --sock-path=/tmp/ruby-lsp-debug-sockets/ruby-debug-my_repo-1.sock -- bundle exec rspec spec/domain/money_spec.rb 2023-11-27 15:11:16.267 [info] Environment {...}

- When I run the debugger in my app code started using F5 to start VSCode with the extension in dev mode...
  - It did not stop at the breakpoint
  - It did not log anything else to console
  - My test did not run.

Please let me know what ya think a good set of next steps are!!

[vinistock]

If you try to boot the debugger manually from the terminal with the exact command we ran, does it show any output?

bundle exec rdbg --open --command --sock-path=/tmp/ruby-lsp-debug-sockets/ruby-debug-my_repo-1.sock -- bundle exec rspec spec/domain/money_spec.rb

[alexevanczuk]

No – it just hangs 🤔

[st0012]

What happens when you do this:

bundle exec rdbg --command -- bundle exec rspec spec/domain/money_spec.rb

It should hit a breakpoint with output like:

[4, 13] in ~/.gem/ruby/3.2.2/bin/rspec
     4| #
     5| # The application 'rspec-core' is installed as part of a gem, and
     6| # this file is here to facilitate running it.
     7| #
     8| 
=>   9| require 'rubygems'
    10| 
    11| Gem.use_gemdeps
    12| 
    13| version = ">= 0.a"
=>#0    <top (required)> at ~/.gem/ruby/3.2.2/bin/rspec:9
  Shopify/vscode-ruby-lsp#1    [C] Kernel.load at ~/.gem/ruby/3.2.2/gems/bundler-2.4.18/lib/bundler/cli/exec.rb:58
  # and 14 frames (use `bt' command for all frames)
(rdbg) c   

• If it doesn't do this, then the issue is that debug gem for some reason doesn't work on your machine
• If it works, then try:

bundle exec rdbg --open --command -- bundle exec rspec spec/domain/money_spec.rb

And it should print something like:

DEBUGGER: Debugger can attach via UNIX domain socket (/var/folders/lf/4xqm_gk10ts83_mxrhsz9qf80000gn/T/ruby-debug-sock-501/ruby-debug-hung-wulo-95798)
DEBUGGER: wait for debugger connection...

• If it doesn't show this, the debug gem on your machine is having issue starting under remote debugging mode
• If it does show the output, but you don't see that with

bundle exec rdbg --open --command --sock-path=/tmp/ruby-lsp-debug-sockets/ruby-debug-my_repo-1.sock -- bundle exec rspec spec/domain/money_spec.rb

It likely means /tmp/ruby-lsp-debug-sockets/ doesn't exist yet. You can verify if that's the cause by creating that folder and rerun the same command.

[alexevanczuk]

What happens when you do this:

bundle exec rdbg --command -- bundle exec rspec spec/domain/money_spec.rb

It should hit a breakpoint with output like:

Yes, this works for me and hits that breakpoint and I see that output.

• If it works, then try:

bundle exec rdbg --open --command -- bundle exec rspec spec/domain/money_spec.rb

And it should print something like:

DEBUGGER: Debugger can attach via UNIX domain socket (/var/folders/lf/4xqm_gk10ts83_mxrhsz9qf80000gn/T/ruby-debug-sock-501/ruby-debug-hung-wulo-95798)
DEBUGGER: wait for debugger connection...

This just hangs for me.

• If it doesn't show this, the debug gem on your machine is having issue starting under remote debugging mode
  • If it does show the output, but you don't see that with

bundle exec rdbg --open --command --sock-path=/tmp/ruby-lsp-debug-sockets/ruby-debug-my_repo-1.sock -- bundle exec rspec spec/domain/money_spec.rb

It likely means /tmp/ruby-lsp-debug-sockets/ doesn't exist yet. You can verify if that's the cause by creating that folder and rerun the same command.

This folder exists for me and that command also hangs for me.

Thanks for both your help here. Let me know what you think might be be a good path to investigating the hanging command execution 🤔

[vinistock]

Not sure why debug is hanging, but if it is working without specifying the socket path, then I believe Shopify/vscode-ruby-lsp#876 will end up fixing this.

[alexevanczuk]

Okay – I'm happy to just wait until that's merged and try again! If any new insights come to mind with respect to the hanging, I'm all ears!

Thanks again for the help and helping build this game-changing toolchain for Ruby!! 🙏🏼 🙌🏼

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months

[alexevanczuk]

Hey @vinistock , I tried pointing to main (since there's not a release yet for the PR you linked above), but I'm still seeing a hanging debug process.

In the ruby-lsp output, I see this:

2024-01-29 12:44:15.275 [info] (monorail) Starting Ruby LSP v0.13.4...

2024-01-29 12:44:15.315 [info] (monorail) Ruby LSP is ready

2024-01-29 12:44:35.450 [info] Spawning debugger in directory /Users/alexevanczuk/workspace/monorail
2024-01-29 12:44:35.450 [info]    Command bundle exec rdbg --open --command --sock-path=/tmp/ruby-lsp-debug-sockets/ruby-debug-monorail-0.sock -- bundle exec rspec spec/domain/coinbase/process_coinbase_buy_spec.rb
2024-01-29 12:44:35.450 [info]    Environment {"RBENV_VERSION":"3.2.2",
"MANPATH":"/opt/homebrew/share/man:/opt/homebrew/share/man:::",
"VSCODE_CRASH_REPORTER_PROCESS_TYPE":"extensionHost",
"SHELL":"/bin/zsh",
"RUBY_HEAP_FREE_MIN":"100000",
"TMPDIR":"/var/folders/x6/8d8xl6p936g004s40c6b2qwr0000gn/T/",
"RUBY_DEBUG_LOG_LEVEL":"ERROR",
"HOMEBREW_REPOSITORY":"/opt/homebrew",
"ORIGINAL_XDG_CURRENT_DESKTOP":"undefined",
"MallocNanoZone":"0",
"OBJC_DISABLE_INITIALIZE_FORK_SAFETY":"YES",
"USER":"alexevanczuk",
"COMMAND_MODE":"unix2003",
"RBENV_ROOT":"/Users/alexevanczuk/.rbenv",
"__CF_USER_TEXT_ENCODING":"0x1F5:0x0:0x0",
"RBENV_HOOK_PATH":"/Users/alexevanczuk/.rbenv/rbenv.d:/opt/homebrew/Cellar/rbenv/1.2.0/rbenv.d:/opt/homebrew/etc/rbenv.d:/usr/local/etc/rbenv.d:/etc/rbenv.d:/usr/lib/rbenv/hooks",
"ELECTRON_RUN_AS_NODE":"1",
"VSCODE_AMD_ENTRYPOINT":"vs/workbench/api/node/extensionHostProcess",
"PATH":"/Users/alexevanczuk/.rbenv/versions/3.2.2/bin:/opt/homebrew/Cellar/rbenv/1.2.0/libexec:/opt/homebrew/opt/libpq/bin:/Users/alexevanczuk/.rbenv/shims:/opt/homebrew/bin:/opt/homebrew/sbin:/opt/homebrew/opt/libpq/bin:/Users/alexevanczuk/.rbenv/shims:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/alexevanczuk/.cargo/bin",
"LaunchInstanceID":"341A74DF-ED9C-4317-8DEC-1C88241171F4",
"RBENV_ORIG_PATH":"/opt/homebrew/opt/libpq/bin:/Users/alexevanczuk/.rbenv/shims:/opt/homebrew/bin:/opt/homebrew/sbin:/opt/homebrew/opt/libpq/bin:/Users/alexevanczuk/.rbenv/shims:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/alexevanczuk/.cargo/bin",
"__CFBundleIdentifier":"com.microsoft.VSCode",
"PWD":"/Users/alexevanczuk/workspace/monorail",
"VSCODE_HANDLES_UNCAUGHT_ERRORS":"true",
"EDITOR":"vim",
"XPC_FLAGS":"0x0",
"RBENV_SHELL":"zsh",
"XPC_SERVICE_NAME":"0",
"SHLVL":"2",
"HOME":"/Users/alexevanczuk",
"SPRING_QUIET":"1",
"VSCODE_NLS_CONFIG":"{\"locale\":\"en-us\",
\"osLocale\":\"en-us\",
\"availableLanguages\":{},\"_languagePackSupport\":true}",
"HOMEBREW_PREFIX":"/opt/homebrew",
"RBENV_DIR":"/Users/alexevanczuk/workspace/monorail",
"LOGNAME":"alexevanczuk",
"VSCODE_IPC_HOOK":"/Users/alexevanczuk/Library/Application Support/Code/1.85-main.sock",
"VSCODE_CODE_CACHE_PATH":"/Users/alexevanczuk/Library/Application Support/Code/CachedData/0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2",
"VSCODE_PID":"65223",
"INFOPATH":"/opt/homebrew/share/info:/opt/homebrew/share/info:",
"HOMEBREW_CELLAR":"/opt/homebrew/Cellar",
"RUBYLIB":"/opt/homebrew/Cellar/rbenv/1.2.0/rbenv.d/exec/gem-rehash:",
"VSCODE_L10N_BUNDLE_LOCATION":"",
"VSCODE_CWD":"/",
"RUBYOPT":"--yjit"}

[alexevanczuk]

I also tried switching to the VSCode pre-release extension and it did not resolve the problem – the output just hangs and there's no other observable behavior.

[vinistock]

PR https://github.com/Shopify/vscode-ruby-lsp/pull/989 changes when we throw the debugger error from exit to close. In practice, this means that the backtrace of the debugger server will now show up in the console.

I'm hoping it will make it easier to diagnose whatever is failing here.

Also, are you positive that the version on main was running? We no longer include --sock-path in the options, but that's showing up in your logs.

[alexevanczuk]

I'll definitely retry once that PR is merged so we have more verbose output to debug.

I think I'm positive I'm running on main. It looks like that change is in vscode-ruby-lsp: https://github.com/Shopify/vscode-ruby-lsp/pull/876/files#diff-2561f1eb5eaff5e346e9b7fd47d75997379092bf0ec90287d714fe0c9f5348c9L182

Has there been a pre-release (or release) of the editor extension since that PR has merged? Seems like even the pre-release version of the editor extension has not yet incorporated this change. Not sure how to point to main for the extension.

[vinistock]

I just released new versions which include the changes I mentioned. Can you please try again? And if it doesn't work, is there any backtrace in the debug console that helps diagnose?

[alexevanczuk]

Hey @vinistock thanks for the update.

I tried with ruby-lsp on main and the newest version of the VScode extension released on 1/30/24.

It didn't work unfortunately – still seeing the same output as before (no backtrace in console).

[vinistock]

Could something be redirecting the STDOUT, STDERR pipes somehow? I'm honestly clueless as to why there's no backtrace showing some problem.

@st0012 any ideas?