-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ruff logging core dump messages in the system journal #12545
Comments
Thanks for reporting. It will probably be difficult for us to fix this without additional information. What I see from the log is that the failing command is Have you ever noticed any VS Code error dialog telling you that it restarted the Ruff server because it crashed? If so, would you mind sharing the logs (see troubleshooting section) with us? That would greatly help in getting to the bottom of this. |
@MichaReiser I've enabled logging for Neovim as described here. Here is the output of
|
Are there any indications in the editor that the server crashed (notifications?) because there's none in the provided logs? Do you still see the diagnostics and are they being refreshed when you change the buffer content after the crash? |
There are no notifications in the editor indicating that the server has crashed. And I still see the diagnostics, and they are being refreshed when I change the buffer content even after the crash. Here is a backtrace that I hope will help in identifying the issue:
|
Thanks for sharing the backtrace. Looking at the code it seems to me that we panic inside the ruff/crates/ruff_server/src/message.rs Lines 36 to 41 in 507f5c1
Maybe we should change the server code to use @Fissium could you try setting the |
Shouldn't it also have notified the user about the panic via notification? It didn't in this case (#12545 (comment)) which is weird because the messenger is set in the |
Possibly. It may have failed. We ignore the return type. What I suspect is happening is that the stderr stream gets closed by neovim (e.g. when exiting the editor?). We then try to write a message which panics and so will |
Hmm, that's interesting because the author mentioned that the server keeps running (or is it being restarted by the editor?) and it even refreshes the existing diagnostics. |
@MichaReiser Here is the log file: |
Thanks @Fissium this is very helpful!
It does seem that the server panics after receiving the exit message, because of a broken pipe |
I tried to reproduce this error with the following neovim configuration but without success local lspconfig = require 'lspconfig'
vim.lsp.set_log_level(vim.env.NVIM_LSP_LOG_LEVEL or vim.lsp.log_levels.DEBUG)
require('vim.lsp.log').set_format_func(vim.inspect)
lspconfig.ruff.setup {
cmd = { "/home/micha/astral/ruff/release/debug/ruff", "server" },
cmd_env = { RUFF_TRACE = "verbose" },
init_options = {
settings = {
logLevel = "trace",
logFile = "~/ruff.log",
}
}
} |
I merged a fix for the panic. Let me know if you keep seeing the core dump messages after upgrading. And thanks again for all your help with providing crash reports! |
@MichaReiser After upgrading to 0.5.6, I don't see any core dump messages. Thank you! |
I've noticed that ruff continues to run, but there are frequent core dump messages logged in the system journal. Below are the details from the most recent log entry:
ruff version:
0.5.5
system:
Arch Linux
pyproject.toml
The text was updated successfully, but these errors were encountered: