100% CPU usage #2446
Comments
|
@tsvallender if you are able to share the LSP logs from just before it causes the CPU to peak, then that may help us to diagnose the problem. Also, are you are on the latest release? (v0.17.13) |
There hasn't been anything extra in the logs, and yes latest release. A colleague suggested stracing the process next time it happens so will see if that suggests anything. Always the way it doesn't happen when you're waiting for it... |
|
I've had a hang somewhat recently (like maybe 1 month ago) as well but Signal.trap("SIGUSR1") do
output = +""
Thread.list.each do |thr|
output << ("-" * 40) << "\n"
output << thr.inspect << "\n"
output << thr.backtrace.join("\n") << "\n"
end
File.write("ruby-lsp-trace.log", output)
end if Signal.list.include?("USR1")You can then do This is all a bit awkward with the server auto-updating and all that, I wonder if this would be a generally useful addition for debugging things like this. There have been a few other issues with CPU pegging as their topic. |
|
So it’s happened again, which is nigh-on ungrokkable to me I’m afraid, is it of any use to anyone else?
Great idea, I’ve just added that and verified it’s working so will try it next time… |
|
Okay, so with that bit of code added in, I get the below, which to me seems to be pointing at this loop becoming infinite? |
|
Certainly looks like something that could happen there, thought the only way I can think of is when edits are received out-of-order. I coincidentally had another case today myself, though I failed to capture a stacktrace (oops). I'm going to add some logging to that method should we be running into the same thing. |
|
We received other reports of this and the thread is quite helpful. The referenced loop essentially turns a line + character position into the index that represents that position in the string we use to store the document's source code. I'm not sure how we wouldn't be able to find the requested line and end up in an infinite loop though. We process text edits under a mutex lock, exactly to avoid having a feature request like signature help landing in between a thread switch (and thus trying to execute in a partially updated document). If anyone can reproduce this reliably, we need to understand what piece of code triggers the problem. Alternatively, we can also raise from that method if we reached the end of the document without finding anything and then include the state of the document and the position we were looking for. That might help diagnose it. |
|
I've been chasing this one for a few months now as well. An alternative method I've used to capture the stack trace reliably is the I've observed two things when this has triggered:
I theorized that we were thrashing the GC somehow but wasn't able to get any deeper. It's near impossible to trigger by hand or via |
|
if it's helpful, this triggers on my machine almost always now - to the point i've had to uninstall and i reinstall when i see an update is pushed - but if there are commands or anything that you would like me to run to help diagnose i am more than willing to help. i'm on an intel mac still, if that matters. i uninstalled it because i just got tired of it melting my battery down so quickly with bash processes that run 100%. |
|
I think adding an explicit error message if the scanner fails to find the right position will help diagnose this. I'll put something up for this. @denvermullets meanwhile, a few questions to try to understand what's going on:
|
sorry, missed this.
|
|
I've just had this happen to me again and the window I had open at the time was a git diff, and that file is just boring utf8. I noticed this while benchmarking and the average went way up so I'm confident it happened then. I unfortunatly had no way to debug this since the server updated and I didn't put my things back in. strace only showed this: |
|
This one happens to me essentially every day, neovim, M2 MacOS. I can help diagnose if someone points me in the right direction, no strace on MacOS so I can take a look with dtrace or equivalent perhaps. |
|
I think it would be handy if anyone sees it again to capture a recent stacktrace. Looking at the stacktrace above, it seems a bit out of date. |
I can reliably reproduce this, my only issue is I only run MacOS and BSD at the moment, I'll see if I can get this going on a Linux box with strace. Maybe I'll see you in IRC later @adam12 |
Yeah, Mac ruined strace/dtruss didn't they :( You can install I've found this mechanism the most reliable.
I'm around 😎 |
|
I'll see if I can get this with a more up to date ruby-lsp, although I'm having trouble tricking neovim into using the latest version for some reason. |
|
Another idea might be running with I have been running with Here's my Lua config. local lspconfig = require('lspconfig')
lspconfig.ruby_lsp.setup({
cmd = { 'ruby-lsp', '--debug', },
})You'll want |
|
I'm still puzzled by this, but if people are willing to help diagnose this PR #2664 has a bit more machinery to help. Essentially, if the scanner fails to find the requested position, then we raise and print to the output tab the document state and the requested position that caused the failure. This should hopefully help us understand if the document state got corrupted. To test on that branch, I believe it would be enough to put the |
|
Possibly of note is that I changed machine recently, and haven't had this issue since, despite having the same Neovim setup. So one fix is to buy a new PC 😅 |
|
I'll post another update if I see it, but I actually think updating to the latest |
|
@Aesthetikx which vim distribution is that? |
In this particular case LazyVim, which I do update regularly, I think however the issue is that it is not part of the LazyVim update screen, it is |
|
I'm not familiar with LazyVim or Mason, but there is an example config here that might help: |
|
I have been sporadically running into this problem, too. I have not yet been able to reproduce it, however.
$ nvim --version
NVIM v0.10.0
Build type: Release
LuaJIT 2.1.1713484068
Run "nvim -V1 -v" for more info |
|
i spent a few hours this morning trying to resolve this and noticed that it's stuck on starting:
i'm using asdf w/vs code and have been trying different settings to see if there's a connection there. i also tried updating my current project to ruby 3.3.5 (was on 3.3.0) and just updated my mac last night to the latest os. i do not have this problem on my work computer which is an M1 vs my personal laptop which is an intel. unsure how that'd be related but just something i've noticed. edit: i'm dumb i didn't realize i had to select the tab and then the dropdown in output to get the error so maybe my error isn't fit for this issue: 2024-10-30 11:27:36.183 [info] (myproject) Checking if chruby is available on the path with command: /bin/zsh -i -c 'chruby --version'
2024-10-30 11:27:39.990 [info] (myproject) Checking if rbenv is available on the path with command: /bin/zsh -i -c 'rbenv --version'
2024-10-30 11:27:43.711 [info] (myproject) Checking if rvm is available on the path with command: /bin/zsh -i -c 'rvm --version'
2024-10-30 11:27:47.378 [info] (myproject) Checking if asdf is available on the path with command: /bin/zsh -i -c 'asdf --version'
2024-10-30 11:27:51.247 [info] (myproject) Discovered version manager none
2024-10-30 11:27:51.247 [info] (myproject) Running command: `ruby -W0 -rjson -e 'STDERR.print("RUBY_LSP_ACTIVATION_SEPARATOR" + { env: ENV.to_h, yjit: !!defined?(RubyVM:: YJIT), version: RUBY_VERSION, gemPath: Gem.path }.to_json + "RUBY_LSP_ACTIVATION_SEPARATOR")'` in /Users/denvermullets/Development/pers/myproject using shell: /usr/local/bin/zsh
it never returns from this unless i force quit the bash process that's 100%'ing |
Description
I am fairly regularly (probably about once a day at a full-time job) having ruby-lsp hit 100% CPU and stay there until I restart the process. I’m using the latest ruby-lsp with the Rails extension, in Neovim. I’ve seen this behaviour in multiple Ruby versions but am mostly in 3.3.4 currently.
I’m more than happy to do some work trying to figure out what’s causing this but am unsure where to start, any pointers appreciated.
The text was updated successfully, but these errors were encountered: