mojo-lsp-server crashing
Is it crashing for anybody else? I'm using it with neovim and I can reliably make it crash after a couple of minutes of using it.
20 Replies
Looks like the issue is related to /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
From what I just found in a quick search, could be related to WSL2 or Hyper-V
Yeah it's crashing for me quite often on nightly with VSCode, I think it's somehow connected with code having e.g compilation errors, if these are present or there's a lot of them it crashes
Yep same behavior for me.
What OS are you using?
Hi! It sounds like this might be the same issue folks are discussing here https://discord.com/channels/1087530497313357884/1224434323193594059/1278068604696264766 – which @Walter Erquinigo is working on a fix for 🙏
Congrats @Caroline, you just advanced to level 2!
Could one share some code snippet that makes the LSP crash?
Congrats @Walter Erquinigo, you just advanced to level 3!
Well, that's tricky because it's not just one code snippet. It's kind of as a2svior described.
Let me try
yeah it's kind of dynamic. I can't just do it with a certain code snippet. I have to produce a lot of errors pretty quickly
The best info I can give you is it is crashing because it tries to open this: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
that file is not implemented for me in WSL2
perhaps it is trying to throttle itself from using too much cpu
I'm on Mac M1 Sonoma
Not sure if this helps, but for me if I clone e.g. the Lightbug repo https://github.com/saviorand/lightbug_http and try to open some files when running a nightly version of the VSCode extension (e.g. if I open external/libc.mojo) it crashes at some point, because the code is not yet migrated to nightly and there's a lot of errors
Has this gotten better with the last nightly?
I'll check and let you know.
Congrats @xentropy, you just advanced to level 3!
Looks like it's still trying to access this non-existent file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
I'm running WSL2 with Ubuntu and that whole cpufreq path is missing.
I'm almost sure that the
scaling_cur_freq error message is benign. It's used to compute some performance bits when available for telemetry.
What I think is the actual error is the following:
I'll have someone on the team debug this