lsp: constant 100% cpu usage

[Im-Beast]

OS: Arch (5.16.1-arch1-1)
Deno version: 1.18
Code Editor: VSCodium

deno lsp gets stuck on 100% after trying to save a file.

Reproduction:

1. Create empty .ts file
2. Save file (while having formatting on save enabled)

[dsherret]

@Im-Beast do you have some other reproduction steps? I'm not able to reproduce.

I bet probably some other lsp request is getting stuck doing something and then when the formatting request occurs that gets blocked on the other work that's being done.

[Im-Beast]

I have no other way to reproduce it, it happens on every file on my pc since 1.18 update :/

[dsherret]

@Im-Beast hmmm... I've been trying a bunch of stuff, but still haven't been able to reproduce. Would you be able to provide the output of View > Output > then select "Deno Language Server" in drop down? Also if it loads (probably won't), the "Workspace Settings" section when doing Deno: Language Server Status from the command pallette?

[Im-Beast]

@dsherett
This is really unfortunate, i tried playing with settings, tried to downgrade vscodium (as other possible point of failure) and couldn't stop it from happening.
In answer to your question, here is the screenshot:

[Im-Beast]

I downgraded deno to 1.17.1 just to be sure whether its deno's issue. While using version 1.17.1 issue doesn't persist.

[dsherret]

@Im-Beast would you be able to provide your "Workspace Settings" in 1.17.1? I've been going over code changes since 1.17.1 and nothing stands out at the moment. Hopefully I'll be able to reproduce if I use the same workspace settings.

[dsherret]

By the way, does it happen in 1.17.2 and 1.17.3? Sorry for all the questions...

[remyrylan]

This may not be a very helpful reply, but I consistently hit this issue when I do find/replace across 25+ files and deno fmt is called on each one via automatic IDE integration (VS Code Deno Extension, etc..).

[dsherret]

@jrylan in that case it eventually completes though, right? In this case it gets stuck. I believe for that scenario the changes in #11307 would make it much faster because some formatting requests could occur in parallel.

[remyrylan]

@dsherret no, I've waited for several minutes and it doesn't complete. The Deno LSP hangs at 100% CPU and eventually VS Code freezes on macOS. When I reopen VS Code, the session is restored with the files modified in the editor, but marked as unsaved (the session restores the file contents from temp files).

It does seem like #11307 would help a lot.

[Im-Beast]

@dsherret
I think that I figured out why it was broken
I had this piece in my .vscode/settings.json

  "deno.suggest.imports.hosts": {
    "https://deno.land": false
  }

After I've removed it and restarted vscode it started working normally, very odd

If you still want me to, i'll check whether issue occurs in 1.17.2/3

[dsherret]

@Im-Beast very strange... I tried adding that and wasn't able to reproduce again. @kitsonk might know what's going on here. In your folder with an empty typescript file, do you have other files? Also, would you be able to provide your workspace settings ("Workspace Settings" section when doing Deno: Language Server Status from the command pallette)? Thanks!

[Im-Beast]

@dsherret I cannot reproduce this issue again, even on 1.18 which makes it even more strange. Yet to know what fixed or caused it tho.

My workspace settings if they're in any way relevant:

{
  "enable": true,
  "cache": null,
  "config": null,
  "importMap": null,
  "codeLens": {
    "implementations": false,
    "references": false,
    "referencesAllFunctions": false,
    "test": true
  },
  "internalDebug": false,
  "lint": true,
  "suggest": {
    "completeFunctionCalls": false,
    "names": true,
    "paths": true,
    "autoImports": true,
    "imports": {
      "autoDiscover": false,
      "hosts": {
        "https://crux.land": true,
        "https://deno.land": true,
        "https://x.nest.land": true
      }
    }
  },
  "unstable": false
}

[kitsonk]

I am not sure specifically what is going on either, but I did have a lockup like this yesterday as well. It feels very much like a deadlock issue which we have had before. I wrote it off as just having an unstable environment. Let's keep the issue open and see if we get more reports. @dsherret I think we need to think about with any of the recent refactors between 1.17 and 1.18 if we could have gotten into a deadlock issue. There were a few lsp changes that didn't get put into 1.17.3 patch release, but I think we need to really link about any mutexes we have introduced recently in the lsp and figure out if they can possible result in a deadlock.

[gm112]

@dsherret I cannot reproduce this issue again, even on 1.18 which makes it even more strange. Yet to know what fixed or caused it tho.

My workspace settings if they're in any way relevant:

{
  "enable": true,
  "cache": null,
  "config": null,
  "importMap": null,
  "codeLens": {
    "implementations": false,
    "references": false,
    "referencesAllFunctions": false,
    "test": true
  },
  "internalDebug": false,
  "lint": true,
  "suggest": {
    "completeFunctionCalls": false,
    "names": true,
    "paths": true,
    "autoImports": true,
    "imports": {
      "autoDiscover": false,
      "hosts": {
        "https://crux.land": true,
        "https://deno.land": true,
        "https://x.nest.land": true
      }
    }
  },
  "unstable": false
}

Maybe it could be worth trying some things. Such as simulating high latency on your end to the repositories? Another thing would be worth trying is overloading your network traffic with other tasks, things of that nature.

[Im-Beast]

@gm112 I don't see how network traffic is relevant here

[gm112]

Its just a suggestion of something to try to replicate the conditions that resulted in a deadlock. Surely something was different between the runs.

[dsherret]

Yeah, network traffic could be relevant. When I was trying to reproduce this I was trying out simulating the registries being down and also tried clearing my cache, but I still wasn't able to reproduce it.

That said, in #13485 we discovered one potential deadlocking situation. Maybe this will fix the issue in 1.18.1 once released later this week. If not, I'll re-open this issue and continue investigating.