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 |
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: