-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
SIGSEGV During regular operation #21467
Comments
Apologies for the lack of information, I'm a relative noob with systems debugging. |
Nothing useful in the backtrace which leads me to believe this is a bad install. |
On nix here aswell, and im facing the same problem. |
I'd be very surprised if it were considering this is built from a Nix package, where the main focus is reproducible builds. I can investigate further into it being a config issue though. |
Not encountering this issue on You can try $ nix run "github:neovim/neovim?dir=contrib" -- --clean |
Is it possible to get a backtrace or a core dump from a debug build? |
I will run the suggested nix version above later on and report back. Do you have docs for building a debug binary with nix in case the unstable build doesn't fix it. |
After some amount of testing on 0.9.0, I cannot reproduce it. This could also just be because the LSPs are disabled, so I will test further tonight if LSPs are causing the problem. |
The following runs a debug build for Neovim 0.8 $ nix run "github:neovim/neovim/release-0.8?dir=contrib#neovim-debug" -- --clean
NixOS wraps Neovim with your config, in the commands I gave I added $ nix build "github:neovim/neovim/release-0.8?dir=contrib#neovim-debug" # the build ends up in ./result
$ cp $(which nvim) ./nvim.sh
$ chmod +w ./nvim.sh
$ nvim ./nvim.sh # edit the last line, replacing Neovim's executable path with `./result/bin/nvim`
$ ./nvim.sh |
Thanks! I'll give it a go now. |
Update, got a SIGABRT (??), going to gather the traceback and send it over. |
Command Line: ./result/bin/nvim
GNU gdb (GDB) 12.1 For help, type "help". warning: Can't open file /run/nscd/dbl9tGUY (deleted) during file-backed mapping note processing warning: Section warning: Section `.reg-xstate/45817' in core file too small. |
Unfortunately still not really anything useful to get much insight from. Looks like libuv is just crashing hard. |
Unfortunately so. I could look into disabling LSPs and such to see if it resolves it tomorrow. |
Disabled the following, issue still appeared:
As they all have IO at some point. Still unsure what's causing it lol. |
More info: Got |
Managed to get gdb attached and captured the error, stack: libluv is definitely dying.
|
One interesting note I forgot to mention was neovim spawning a whole load of child processes? Every time i switched windows, GDB logged about child process detaching, which i found weird. Is this expected / intended? |
Not intended, it's an ongoing problem we're trying to fix. Any help is welcome. |
Alright, thanks for that! Thought it might have been related in some sense, not sure though.. All I can say is that it's still spawning a lot of processes. At least that rules out a plugin making processes and crashing. |
After getting many crashes today, I do believe it is related to the file saving logic. I have an autosave plugin (entirely lua, only calling neovim APIs), so when I leave |
NixOS/nixpkgs#218939 (comment) I have the same problem, I use pure lua config and use nix to install treesiiter. But it can't work. |
luvit/luv#633 maybe this problem because of this |
Yep, can repro that. It crashed mine. Can't say for certain that this is the same bug, but its certainly something. Thanks for the update! |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Looks like updating luv might help? luvit/luv#634 (thank you @Bilal2453 !) |
EDIT: Can't get the overlay to work lol. |
Something is definitely going wrong with the thread code. It seems to be mainly triggered by the argument setting, I can't really debug this effectively as gdb is reporting a different backtrace on the thread segfaulting. The actual segfault seems to happen after the arguments error, possibly somewhere in Will open an issue on the Luv repo later on, still not entirely sure if it is related but it is consistently segfaulting for me so worth mentioning. |
Can you try #22502? |
Recently redid my config and this issue seems to have gone. Could still be a neovim core issue which was triggered by an odd set of plugins, but i'm not sure. Closing for now. |
Neovim version (nvim -v)
NVIM v0.8.1
Vim (not Nvim) behaves the same?
no, 9.0
Operating system/version
NixOS 23.05.20221214.2f38822 (Stoat) x86_64
Terminal name/version
wezterm 20221119-145034-49b9839f
$TERM environment variable
xterm-256color
Installation
nixpkgs
How to reproduce the issue
Segfaulting appears in regular operation, inconsistently.
Expected behavior
Neovim works without segfaulting.
Actual behavior
Neovim segfaults. Backtrace:
Command Line: gdb /nix/store/39xg6gawi83swjp15y0d8yglv81kx8b9-neovim-unwrapped-0.8.1/bin/nvim -c /run/user/1000/coredump-XXC1VT
Executable: /nix/store/ghvw9lxj8wy3qjip2jv6qsqwvqh6r86j-gdb-12.1/bin/gdb
Control Group: /user.slice/user-1000.slice/session-2.scope
Unit: session-2.scope
Slice: user-1000.slice
Session: 2
Owner UID: 1000 (amy)
Boot ID: 77c76e7d8f5b4897ae66405eca23feeb
Machine ID: 84cac12fbb954a6c87b564a1d614a61b
Hostname: nixon
Storage: /var/lib/systemd/coredump/core.gdb.1000.77c76e7d8f5b4897ae66405eca23feeb.78517.1671395869000000.zst (present)
Size on Disk: 4.4M
Message: Process 78517 (gdb) of user 1000 dumped core.
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
https://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /nix/store/ghvw9lxj8wy3qjip2jv6qsqwvqh6r86j-gdb-12.1/bin/gdb...
(No debugging symbols found in /nix/store/ghvw9lxj8wy3qjip2jv6qsqwvqh6r86j-gdb-12.1/bin/gdb)
[New LWP 78517]
[New LWP 78519]
[New LWP 78521]
[New LWP 78523]
[New LWP 78524]
[New LWP 78526]
[New LWP 78534]
[New LWP 78525]
[New LWP 78528]
[New LWP 78530]
[New LWP 78522]
[New LWP 78529]
[New LWP 78532]
[New LWP 78533]
[New LWP 78527]
[New LWP 78520]
[New LWP 78531]
warning: Section
.reg-xstate/78517' in core file too small. [Thread debugging using libthread_db enabled] Using host libthread_db library "/nix/store/4nlgxhb09sdr51nc9hdm8az5b08vzkgx-glibc-2.35-163/lib/libthread_db.so.1". Core was generated by
gdb /nix/store/39xg6gawi83swjp15y0d8yglv81kx8b9-neovim-unwrapped-0.8.1/bin/nvim'.Program terminated with signal SIGSEGV, Segmentation fault.
warning: Section `.reg-xstate/78517' in core file too small.
#0 0x00007f561ec78bc7 in __pthread_kill_implementation () from /nix/store/4nlgxhb09sdr51nc9hdm8az5b08vzkgx-glibc-2.35-163/lib/libc.so.6
[Current thread is 1 (Thread 0x7f561c8ceec0 (LWP 78517))]
�[?2004h(gdb) �[?2004l
quit
The text was updated successfully, but these errors were encountered: