Memory leak, Zed editor

[ZombieHarvester]

Description

I keep getting memory leaks when working on my Rails project in Zed editor on Mac. Ruby consumes 50-80 GB of memory. Nothing suspicious in the Ruby LSP logs. Happens randomly after hours of work, no reproducible steps. The only observation, is that I see stuck "Finding references..." at the moment of memory bloat in the Zed bar. "Restart language server" command helps release the memory.

Ruby LSP log

Initializing Ruby LSP v0.23.11 https://github.com/Shopify/ruby-lsp/releases/tag/v0.23.11....
Using formatter specified by user: standard
Using linters specified by user: standard, standard
Detected test library: rspec
Finished initializing Ruby LSP!
Activating Ruby LSP Rails add-on v0.4.0
Ruby LSP Rails booting server
Finished booting Ruby LSP Rails server

Zed log

2025-02-28T16:54:24.881016+04:00 [WARN] Find all references via ruby-lsp failed: LSP request timeout
2025-02-28T16:57:04.87462+04:00 [WARN] Get document highlights via ruby-lsp failed: LSP request timeout
2025-02-28T16:57:08.986725+04:00 [ERROR] Get code actions via ruby-lsp failed: LSP request timeout
2025-02-28T16:57:08.991053+04:00 [ERROR] Get code actions via ruby-lsp failed: LSP request timeout
2025-02-28T16:57:08.991235+04:00 [ERROR] Get code actions via ruby-lsp failed: LSP request timeout
2025-02-28T16:57:08.991385+04:00 [ERROR] Get code actions via ruby-lsp failed: LSP request timeout
2025-02-28T16:57:12.487661+04:00 [ERROR] Find all references via ruby-lsp failed: LSP request timeout
2025-02-28T16:57:49.752132+04:00 [ERROR] cannot read LSP message headers
2025-02-28T16:57:49.781191+04:00 [WARN] Get code actions via ruby-lsp failed: oneshot canceled
2025-02-28T16:57:49.781404+04:00 [WARN] Get definition via ruby-lsp failed: oneshot canceled
2025-02-28T16:57:49.781568+04:00 [WARN] Get document highlights via ruby-lsp failed: oneshot canceled
2025-02-28T16:57:49.793609+04:00 [ERROR] Get code actions via ruby-lsp failed: oneshot canceled
2025-02-28T16:57:49.819749+04:00 [ERROR] Get document highlights via ruby-lsp failed: oneshot canceled

Ruby: 3.3.7
Version manager: asdf
Zed: v0.175.6 (Zed)
OS: macOS 12.7.6
Memory: 16 GiB
Architecture: x86_64

Zed settings:

  "languages": {
    "Ruby": {
      "show_edit_predictions": true,
      "tab_size": 2,
      "language_servers": [
        "ruby-lsp",
        "!rubocop",
        "!tailwindcss-language-server",
        "!solargraph",
      ],
      "formatter": "language_server",
      "format_on_save": "on",
    }
  },
  "lsp": {
    "ruby-lsp": {
      "initialization_options": {
        "experimentalFeaturesEnabled": true,
        "formatter": "standard",
        "linters": ["standard"],
        "enabledFeatures": {
          "codeActions": true,
          "codeLens": true,
          "completion": true,
          "definition": true,
          "diagnostics": false, // until Zed supports pull-type diagnostics
          "documentHighlights": true,
          "documentLink": true,
          "documentSymbols": true,
          "foldingRanges": true,
          "formatting": true,
          "hover": true,
          "inlayHint": true,
          "onTypeFormatting": true,
          "selectionRanges": true,
          "semanticHighlighting": true,
          "signatureHelp": true,
          "typeHierarchy": true,
          "workspaceSymbol": true
        },
        "featuresConfiguration": {
          "inlayHint": {
            "implicitHashValue": true,
            "implicitRescue": true
          }
        }
      }
    },
  },

ruby-lsp-check also pushes memory. It got to 89 GB before getting killed on 352/2150

Completed 352/2150[1]    72400 killed     ruby-lsp-check

[vinistock]

Thank you for the report! Finding references is indeed a memory and CPU intensive process because the LSP needs to do a lot of work to find all possible places where something might be used. I'm curious, do you see the memory leak even when not using find references? Or is this specific to that feature?

[ZombieHarvester]

@vinistock I don't know. Memory hogging is not instant, it grows over a minute or two. I notice only after the system becomes unresponsive. So I'm not sure which action exactly led to it.

Only after the lagging I notice the "Finding references..." hint. It seems it's connected with the memory bloat, it disappears before the memory release.

Pls notice I've updated the post, added memory issue with the ruby-lsp-check

[ZombieHarvester]

Is there a way to troubleshoot this? This is very annoying, happened twice today

[jwoodrow]

Any update on this ?

We use VSCode and dev containers (with Orbstack) and after a while we notice the memory being used by Docker/Orbstack bloats out of control until it disconnects completely and requires a full shutdown and restart of Docker.

We didn't used to have this before switching to ruby-lsp as a VSCode extension

[ZombieHarvester]

@jwoodrow I solved it by setting excludedPatterns to exclude the problematic files from indexing. Not ideal, but worked.

https://shopify.github.io/ruby-lsp/vscode-extension.html#indexing-configuration

[jwoodrow]

Thanks @ZombieHarvester I'll try and see how to identify the problematic files, any tips on how you proceeded to do this ?

[ZombieHarvester]

@jwoodrow There’s a ruby-lsp-check tool for troubleshooting (see https://shopify.github.io/ruby-lsp/troubleshooting.html#indexing).

It confirmed the memory leak but didn’t identify the files causing it. I grabbed its source (https://github.com/Shopify/ruby-lsp/blob/main/exe/ruby-lsp-check), added debugging info, and ran it manually, which helped me pinpoint and exclude the problematic files from indexing.

Hope it helps!

P.S. In my case, the files causing the leak were a large seeds file (thousands of lines with ActiveRecord model calls) and some legacy Ruby 1.8 files stored in a separate folder for reference.

[vinistock]

@ZombieHarvester are you able to share the code patterns used in those files? I'm just wondering if there's some Ruby pattern that causes the indexing to blow up in CPU/memory consumption.

If it's just the fact that the file is super long, well indeed processing large files takes more resources and time (and if they aren't relevant in the context of the rest of the codebase, excluding is the way to go).

However, if there's some sort of circular reference or structure that degrades performance, we can look into fixing that.

[vinistock]

I'll close this for now. Please let us know if you see it again or if you identify any patterns that slow down the LSP.