Little to no info if debugger exits with error code

[MartyBeGood]

Operating System

Ubuntu 22.04 LTS

Ruby version

3.2.2

Project has a bundle

• Has bundle

Ruby version manager being used

other (please specify in description)

Description

There seems to be an environmnt issue in one of my projects. rdbg from the command line works. Ruby-LSP in vscode works. Ruby-LSP in nvim works. But I can't get vscode-ruby-lsp to produce a working debugging config.

On ruby version management: We have our own way of managing ruby versions/paths/gem locations. Other projects using this version management on the same machine debug fine with vscode-ruby-lsp by setting the 'version manager' setting to 'none'.

No matter what I try to debug in this project, I get an error dialog from VSCode saying that the debugger exited with code 127. Even zero-dependency scripts (puts("Hello world!")) refuse to be debugged.
I'm aware that this usually means some command was not found. But this is the only bit of info I get, so I'm not sure how to track this issue down.
There's nothing in the extension output of either Ruby LSP or rdbg. There's nothing in the webview console. My launch.json is empty (the error dialog offers to take me there, then creates a default one).

I'm not asking for help with fixing my environment. I'd just like some form of logging output giving me hints on which command wasn't found, maybe a path that was tried or the config that was generated.

[vinistock]

Thank you for the bug report! Understanding the problem better will clarify what information is helpful to diagnose.

Starting a debug session always runs the same command, which is Ruby debug's executable rdbg.

You mentioned you don't have a launch.json configuration file. Are you debugging through the Debug code lens then? How are you triggering the debug session?

Do you have debug in the project's Gemfile? And if not, did the LSP properly generate a .ruby-lsp/Gemfile with a debug entry?

Finally, can you share your Ruby LSP configurations in VS Code?

[MartyBeGood]

Absolutely!

Starting a debug session always runs the same command, which is Ruby debug's executable rdbg.

If I read the error message correctly, the debugger (=rdbg) exits with 127. I read that as rdbg not finding a command. That would be the thing I'm trying to debug, I guess.

I started noticing it when clicking the Debug code lens, yes. I also had the ruby-lsp-rspec extension installed since we use rspec in our projects.
Then I started trying things to narrow down where things go wrong, so I created a launch.json with the default entries and removed all ruby-lsp extensions.
Turns out, trying to debug ruby scripts behaves the same way in this project, so I'll try and track down why debugging ruby derp.rb fails before I re-add the lsp extensions.

In both projects (debuggable and non-debuggable), I created the following files:

# derp.rb
sum = 2+2
squared = sum * sum
puts(squared)

// .vscode/launch.json
  {
  // 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 script",
      "request": "launch",
      "program": "ruby ${file}" // This is the configuration I tried to use to debug derp.rb
    },
    {
      "type": "ruby_lsp",
      "name": "Debug test",
      "request": "launch",
      "program": "bundle exec bin/rspec ${relativeFile}"
    },
    {
      "type": "ruby_lsp",
      "name": "Attach debugger",
      "request": "attach"
    }
  ]
}

The non-debuggable project has the following Gemfiles:

# Gemfile
# Rails and a bunch of other dependencies
group :development, :test do
  gem "debug", require: false
end

# .ruby-lsp/Gemfile
# This custom gemfile is automatically generated by the Ruby LSP.
# It should be automatically git ignored, but in any case: do not commit it to your repository.

eval_gemfile(File.expand_path("../Gemfile", __dir__))
gem "ruby-lsp", require: false, group: :development

The project in which I can debug has the following Gemfiles:

# Gemfile
# Rails and a bunch of other dependencies. No mention of 'debug'

# .ruby-lsp/Gemfile
# This custom gemfile is automatically generated by the Ruby LSP.
# It should be automatically git ignored, but in any case: do not commit it to your repository.

eval_gemfile(File.expand_path("../Gemfile", __dir__))
gem "ruby-lsp", require: false, group: :development
gem "debug", require: false, group: :development, platforms: :mri

I tried removing the 'debug' dependency from the Gemfile and using the exact .ruby-lsp/Gemfile from the debuggable project in the non-debuggable project, restarted ruby-lsp and tried debugging again. No change in behaviour. Still exit code 127.

Ruby-LSP config (only mentioning non-default values):
Formatter: rubocop
Experimental features: on
Ruby version manager: user setting is "custom", setting in both workspaces is "none"
Custom Ruby Command: user setting is "eval "$(rtx env -s zsh)"", but is ignored in both workspaces because of the version manager setting

[vinistock]

Ruby version manager: user setting is "custom", setting in both workspaces is "none"

Shouldn't this be custom, so that it runs your rtx activation? If you use none, the extension will pick up environment variables from when you opened VS Code. Depending on which project you opened VS Code on, it could be pointing to different Ruby versions or gemset configurations.

Also, if you just run the debug activation manually, does it work?

BUNDLE_GEMFILE=.ruby-lsp/Gemfile bundle exec rdbg --open --command --sock-path=/tmp/ruby-lsp-debug-sockets/test.sock -- ruby derp.rb

[MartyBeGood]

I don't want to use rtx in those two projects, so I figured none was the right setting.

Both projects are on a remote machine that I access through SSH (using vscode remote ssh). The server gets started from the parent directory of the two projects (so one level up from the respective project roots). ruby-lsp gets launched from the correct location and with the correct working directory.

Thank you for the rdbg command! I ran that and it exited with code 127 in the project that's giving me trouble. It also gave me a single line of output that said it ran into a problem on Line 4 of the rdbg bin, where it could not find ruby.
I took a look at the source ofrdbg and found out it was broken - there's some weirdness going on that is definitely not related to ruby-lsp.

Thank you for taking the time to point me in the right direction!

It would be amazing to have an option to log the output of the debug command vscode-ruby-lsp runs - or just the command itself - so that the extension can point users in the right direction.

[vinistock]

The server gets started from the parent directory of the two projects (so one level up from the respective project roots). ruby-lsp gets launched from the correct location and with the correct working directory.

We don't have multi workspace support yet #1510, so I don't think this is accurate. If you're opening a directory with two projects inside, the Ruby LSP will likely start at that level, without any knowledge of the two Gemfiles for each project.

That means it will have no knowledge of either projects dependencies. It's also likely why debugging could be failing, since we use the current directory as part of running the command.

Can you try opening just one of the projects in VS Code? If that works, then the issue is most certainly multi workspace support.

[MartyBeGood]

I keep alluding to stuff I don't mean to allude to. Sorry about that!

Can you try opening just one of the projects in VS Code? If that works, then the issue is most certainly multi workspace support.

This is what I have been doing all along.

The relevant part of my remote machine looks like this:

home
└── martybegood
    └── projects
        ├── borked
        ├── debuggable
        └── other

I open one of the projects in ~/projects at a time from the 'recent folders' list. They got there by

1. Connecting vscode to the remote host via ssh
2. telling vscode to open the folder borked (or debuggable, or any other)

When I do that (let's say I opened ~/projects/borked)

• I get a bunch of node processes that get run with a cwd of ~/projects/.
• I get all of the project-aware dependencies (solargraph, ruby-lsp, etc.) run with a cwd of ~/projects/borked.

All of this seems good.

Again, I now found the root cause of the issue that was preventing me from debugging in the borked project:
For reasons unknown to me (yet), running bundle install in the borked project creates binaries in my GEM_HOME/bin for ruby-lsp and rdbg that have a weird preamble:

#!/bin/sh
# -*- ruby -*-
bindir="${0%/*}"
exec "$bindir/ruby" -x "$0" "$@"

#!/path/to/my/ruby/install/bin/ruby

# normal binary contents that would work on their own

This causes ruby_lsp and rdbg to look for ruby exclusively in the GEM_HOME/bin directory. Which fails, unsurprisingly.

Just deleting the preamble (which has shown up a few years ago already) makes things work.

This is not a ruby-lsp problem. I'm aware that it isn't.

What I would have wished for from this extension while debugging this would have been more logging. We get helpful output in case the vscode extension fails to start ruby-lsp (including the command that fails to run and why it fails). We do not get anything other than an error code in a dialog message if rdbg fails.

[vinistock]

I'm glad you figured it out!

I think it would be useful to log the command and environment variables we used to launch the debugger. The question is going to be where to print that - it might be too much text for the error dialogue.

Maybe we can say "look at the output tab for more information" and just print the stuff to the Ruby LSP output channel.

[MartyBeGood]

I think the Ruby LSP output channel would be an ideal place to print this. If ruby-lsp crashes, we get a notification that nudges you that way for more information already: