Stopping debugger does not stop process

[bringel]

Description

Ruby LSP Information

Ruby LSP Information

VS Code Version

1.104.2

Ruby LSP Extension Version

0.9.32

Ruby LSP Server Version

0.26.1

Ruby LSP Add-ons

Ruby Version

3.3.2

Ruby Version Manager

rbenv

Installed Extensions

Click to expand

• Bookmarks (13.5.0)
• EditorConfig (0.17.4)
• JavaScriptSnippets (1.8.0)
• auto-rename-tag (0.1.10)
• better-comments (3.0.2)
• codesnap (1.3.4)
• endwise (1.5.1)
• eslint-disable-snippets (1.4.1)
• file-icons (1.1.0)
• github-vscode-theme (6.3.5)
• gitlens (17.5.1)
• html-end-tag-labels (1.0.0)
• material-theme (3.19.0)
• night-owl (2.1.1)
• openscad (1.3.2)
• openscad-language-support (2.0.1)
• prettier-vscode (11.0.0)
• rainbow-csv (3.22.0)
• redis-for-vscode (1.4.0)
• remote-containers (0.427.0)
• remote-explorer (0.5.0)
• remote-ssh (0.120.0)
• remote-ssh-edit (0.87.0)
• ruby-lsp (0.9.32)
• sort-imports (6.3.1)
• terraform (2.37.2)
• vim (1.30.1)
• vscode-containers (2.2.0)
• vscode-dash (2.4.0)
• vscode-docker (2.0.0)
• vscode-eslint (3.0.16)
• vscode-home-assistant (2.1.0)
• vscode-peacock (4.2.2)
• vscode-pigments (2.0.0)
• vscode-pull-request-github (0.118.2)
• vscode-rdbg (0.2.2)
• vscode-scss (0.10.0)
• vscode-status-bar-format-toggle (3.2.0)
• vscode-tailwindcss (0.14.26)
• vscode-todo-highlight (1.0.5)
• vscode-versionlens (1.22.4)
• vue-vscode-extensionpack (0.2.0)

Ruby LSP Settings

Click to expand

Workspace

{}

User

{
  "enabledFeatures": {
    "codeActions": true,
    "diagnostics": true,
    "documentHighlights": true,
    "documentLink": true,
    "documentSymbols": true,
    "foldingRanges": true,
    "formatting": true,
    "hover": true,
    "inlayHint": true,
    "onTypeFormatting": true,
    "selectionRanges": true,
    "semanticHighlighting": true,
    "completion": true,
    "codeLens": true,
    "definition": true,
    "workspaceSymbol": true,
    "signatureHelp": true,
    "typeHierarchy": true
  },
  "featuresConfiguration": {},
  "addonSettings": {},
  "rubyVersionManager": {
    "identifier": "rbenv"
  },
  "customRubyCommand": "",
  "formatter": "auto",
  "linters": null,
  "bundleGemfile": "",
  "testTimeout": 30,
  "branch": "",
  "pullDiagnosticsOn": "both",
  "useBundlerCompose": false,
  "bypassTypechecker": false,
  "rubyExecutablePath": "",
  "indexing": {},
  "erbSupport": true,
  "featureFlags": {
    "all": true
  },
  "sigOpacityLevel": "1"
}

### Reproduction steps

I have the following launch.json file set up for debugging a sinatra app using puma as the server:

{
  // 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",
      "request": "launch",
      "name": "Debug program",
      "program": "rackup -p 9292",
    }
  ]
}

Clicking the stop button is leaving the puma process around and then trying to start up the server in a terminal or debug again fails because the port is already bound.

1. Start Debugging using the launch configuration
2. Click stop in the debugger toolbar
3. Try to launch again and get this error

Ruby REPL: You can run any Ruby expression here.
Note that output to the STDOUT/ERR printed on the TERMINAL.
[experimental]
  `,COMMAND` runs `COMMAND` debug command (ex: `,info`).
  `,help` to list all debug commands.
[96285] Puma starting in cluster mode...
[96285] * Puma version: 6.6.1 ("Return to Forever")
[96285] * Ruby version: ruby 3.3.2 (2024-05-30 revision e5a195edf6) [x86_64-darwin22]
[96285] *  Min threads: 5
[96285] *  Max threads: 5
[96285] *  Environment: development
[96285] *   Master PID: 96285
[96285] *      Workers: 1
[96285] *     Restarts: (✔) hot (✔) phased (✖) refork
DEBUGGER: Disconnected.
/Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/puma/binder.rb:342:in `initialize': Address already in use - bind(2) for "127.0.0.1" port 9292 (Errno::EADDRINUSE)
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/puma/binder.rb:342:in `new'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/puma/binder.rb:342:in `add_tcp_listener'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/puma/binder.rb:336:in `block in add_tcp_listener'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/puma/binder.rb:335:in `each'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/puma/binder.rb:335:in `add_tcp_listener'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/puma/binder.rb:171:in `block in parse'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/puma/binder.rb:154:in `each'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/puma/binder.rb:154:in `parse'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/puma/cluster.rb:406:in `run'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/puma/launcher.rb:203:in `run'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/puma-6.6.1/lib/rack/handler/puma.rb:79:in `run'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/rack-2.2.17/lib/rack/server.rb:327:in `start'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/rack-2.2.17/lib/rack/server.rb:168:in `start'
	from /Users/bringel/.rbenv/versions/3.3.2/lib/ruby/gems/3.3.0/gems/rack-2.2.17/bin/rackup:5:in `<top (required)>'
	from /Users/bringel/.rbenv/versions/3.3.2/bin/rackup:25:in `load'
	from /Users/bringel/.rbenv/versions/3.3.2/bin/rackup:25:in `<main>'
Debugger exited with status 1.
Please make sure `bundle exec rdbg --open --command -- rackup -p 9292` runs without errors in the terminal.
Check the Ruby LSP output channel for more information.

When the initial debug session starts correctly, it looks like this:

Ruby REPL: You can run any Ruby expression here.
Note that output to the STDOUT/ERR printed on the TERMINAL.
[experimental]
  `,COMMAND` runs `COMMAND` debug command (ex: `,info`).
  `,help` to list all debug commands.
[97344] Puma starting in cluster mode...
[97344] * Puma version: 6.6.1 ("Return to Forever")
[97344] * Ruby version: ruby 3.3.2 (2024-05-30 revision e5a195edf6) [x86_64-darwin22]
[97344] *  Min threads: 5
[97344] *  Max threads: 5
[97344] *  Environment: development
[97344] *   Master PID: 97344
[97344] *      Workers: 1
[97344] *     Restarts: (✔) hot (✔) phased (✖) refork
[97344] * Listening on http://127.0.0.1:9292
[97344] * Listening on http://[::1]:9292
[97344] Use Ctrl-C to stop
[97344] ! WARNING: Detected running cluster mode with 1 worker.
[97344] ! Running Puma in cluster mode with a single worker is often a misconfiguration.
[97344] ! Consider running Puma in single-mode (workers = 0) in order to reduce memory overhead.
[97344] ! Set the `silence_single_worker_warning` option to silence this warning message.
DEBUGGER[/Users/bringel/.rbenv/versions/3.3.2/bin/rackup#97358]: Connected.
[97344] - Worker 0 (PID: 97358) booted in 0.0s, phase: 0

and after clicking stop you can see the process still running with lsof

➜ lsof -i :9292
COMMAND   PID    USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
ruby    97344 bringel    8u  IPv4 0xff85aef6ee898625      0t0  TCP localhost:armtechdaemon (LISTEN)
ruby    97344 bringel    9u  IPv6 0xff85aef216aa424d      0t0  TCP localhost:armtechdaemon (LISTEN)
ruby    97659 bringel    8u  IPv4 0xff85aef6ee898625      0t0  TCP localhost:armtechdaemon (LISTEN)
ruby    97659 bringel    9u  IPv6 0xff85aef216aa424d      0t0  TCP localhost:armtechdaemon (LISTEN)

[vinistock]

Thanks for the report. There are two points here that I think are important.

First, the Ruby LSP only provides a client implementation to connect to the Ruby debug gem. We don't really handle anything related to the life cycle of the process getting debugged. I suspect the Ruby debug gem might be closing the connection to the editor without realizing it entered an infinite loop (the server running).

That said, the second point is that I would probably recommend using attach and not launch for this. The launch task is more typically used for one off things, like running a script or a test. For debugging a long running process like a server, you boot it with the debug gem attached and then fire an attach request, which will connect the editor to your server (see the docs here).

[github-actions]

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