Frequent segfaults in push_fs_result
#644
Comments
|
Is this reproducible with default neovim or is it possible it only happens with some combination of plugins? If possible, knowing the line number of where the crash is happening in |
|
Stacktrace looks similar to one in neovim/neovim#21467 |
|
I'm 99% sure it happens when I have neo-tree enabled, but I can't say for certain. However, I've tried disabling their usage of How would I go about getting the line number? Loading the segfault into gdb only provides me with the stacktrace I have posted above. I'm assuming I can only get the line number out if debug information is compiled in, I'm not sure how I would do that in this case Edit: Just had a look at that thread. One of the stacktraces in there is the exact same as mine, however the command posted in there ( |
|
Compiling neovim from source with debug info would probably work. You could also try the instructions here if that makes anything easier: NixOS/nixpkgs#219400 (comment) EDIT: Just tried and compiling neovim from source is pretty painless, can use The |
|
I'll try that tomorrow and report back. Thanks for the link! |
|
Alright, that was quite the journey since the nix build has been broken for a few weeks on NixOS due to treesitter not being up to date in nixpkgs, but I got one step further. |
happenslol
changed the title
push_fs_resultpush_fs_result
|
Unfortunately the If you're using that |
|
Mhm, no luck so far I'm afraid. I've tried compiling the debug symbols separately and loading them into gdb, but the nixpkgs version seems to be different since I'm getting bogus line numbers. I'm not too experienced with overriding nixpkgs either, I'll try to get some help on the forums for that. Man, nix is amazing when it works, but it makes things like these so complicated... Thanks for your patience! |
|
enabling debug symbol can differ between projects, separateDebugInfo might be one of those case, if you can point me at instructions to enable debug symbols in libuv, we can see how to modify the nix expression together. |
|
Yeah, libuv didn't have
Thanks a lot for the offer still! I learned a lot about overriding things in nix, and I can at least do it for separate targets now. My current way would be building libluv by itself with debug symbols, stripping them out using |
|
Pay attention to neovim/neovim#21413 (comment) |
|
Let's do some analyze.
|
|
Reproduced test("fs.{open,read,close}dir ref check", function(print, p, expect, uv)
local dir = assert(uv.fs_opendir('.', nil, 50))
local function readdir_cb(err, dirs)
assert(not err)
if dirs then
p(dirs)
uv.fs_readdir(dir, readdir_cb)
else
assert(uv.fs_closedir(dir)==true)
end
end
uv.fs_readdir(dir, readdir_cb)
dir = nil
collectgarbage()
collectgarbage()
collectgarbage()
end, "1.28.0") |
|
That reproduction produces a different stack trace for me when I run it via gdb: but I think the fix might solve the |
|
Nevermind, the stack trace is the same as the neovim one if I run it with LuaJIT (I was using PUC Lua since sometimes that makes things easier to debug): |
I'm using the nightly neovim build and am regularly encountering segfaults. I haven't yet 100% narrowed down when they occur, but it mostly seems to be when files are changed while the editor is opened.
This is what the stack trace looks like:
I'm not sure what else to include here, so please tell me if there's any additional information you require.
The text was updated successfully, but these errors were encountered: