Repository navigation
Neovim exits with Abort trap: 6 #15054
Description
Activity
- changed the title
[-]Neovim exits with `Abort trap: 6` from https://github.com/neovim/neovim/commit/3de777d259c379e9fffdf4ebc6aba4059b7400fc[/-][+]Neovim exits with `Abort trap: 6`[/+]on Jul 11, 2021 I was also experiencing this issue on macOS Big Sur 11.4 on aarch64-darwin with the exact same error backtrace. I was on commit 79fe9de, and I can confirm that reverting to a commit before 3de777d prevents the crash. I am building from source with development dependencies installed from MacPorts.
It seemed like the crash would specifically occur when invoking Lua code, for example running
:PackerSyncor invoking telescope.nvim, but I haven't investigated the issue in detail, so I can't narrow the cause.First, how are you building
neovim? Are you using the bundled deps? What is your compiler?I cannot reproduce the crashes using
make installfrom the repo with all bundled deps and the standardclang 12.0.5on either Intel or M1 macOS under iTerm2.Ah, right sorry, forgot to mention that.
make clean && make distclean make CMAKE_BUILD_TYPE=Release CMAKE_EXTRA_FLAGS="-DCMAKE_INSTALL_PREFIX=$HOME/neovim" make installCompiler information:
Apple clang version 12.0.5 (clang-1205.0.22.11) Target: x86_64-apple-darwin20.4.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/binAlso, Justin mentioned this on Gitter:
searching for uv__signal_block_and_lock yields #9274 . nothing recent though. create an issue and include your stacktrace
Without the extra
INSTALL_PREFIX, that is exactly what I do. Maybe it's your terminal -- can you try iTerm2 or the default Terminal.app?Also, I see a
tmuxin your$TERM-- that is always a huge red flag. Are you using tmux?Yes, I fixed that. Now,
$TERM:xterm-kittyand yes, I am using tmux. I tried openingnvimwithout tmux on kitty, on iTerm2 but I still get the error.I just tried to rebuild Neovim on Terminal.app without tmux and I still get the same error. On Terminal.app,
$TERMgives mexterm-256color.Weird. I cannot reproduce this, and the changelog for libluv also doesn't point to any reasonable explanation. Something in your build environment must be different from mine. Can you verify the version of LibUV and LibLUV you are building with? Maybe try building from a fresh clone to make sure that there's no stale dependency lying around (
make distcleanshould take care of it, but at this point I'm grasping at straws).(By the way, the reason homebrew's build behaves differently is because they build dynamically against lib(L)UV version 1.41.0.)
Can you verify the version of LibUV and LibLUV you are building with?
LibUV version:
1.34.2
By LibLUV you mean luv, right?:1.40.0-0Maybe try building from a fresh clone to make sure that there's no stale dependency lying around (make distclean should take care of it, but at this point I'm grasping at straws).
I tried it with the forked repo and also the upstream repo, but both gives me the same error :(
LibUV version:
1.34.2
By LibLUV you mean luv, right?:1.40.0-0Yes. That should be what the build script specifies (and works for me).
I tried it with the forked repo and also the upstream repo, but both gives me the same error :(
Just to make sure, I just mean a fresh
git clone https://github.com/neovim/neovim.git.So I have no idea why your build of neovim behaves differently than mine (and CI's, and most everyone else's).
What's your hardware?
Just to make sure, I just mean a fresh git clone https://github.com/neovim/neovim.git.
Yes, freshly cloned Neovim repo (although using SSH, but I don't think that should make a difference?)
What's your hardware?
MacBook Pro 15-inch 2017 Model Processor 2.9GHz Quad-Core Intel Core i7 Memory 16 GB 2133 MHz LPDDR3Is this the information you're asking for?
Yes, but that is reasonably similar to the machine I am sitting in front of just now. That can't be the explanation.
8 remaining items
Oh damn, great find. Yeah, it seems that the build is picking up the brew installed
luvinstead of the one from the.depsdirectory.@clason Can you try this on your mac? Installing
luvfrombrewand then rebuilding Neovim and checking if this can be reproduced.-- Found LibUV: /Users/dhruvmanilawala/contributing/neovim/.deps/usr/lib/libuv.a (Required is at least version "1.28.0") -- Found Msgpack: /Users/dhruvmanilawala/contributing/neovim/.deps/usr/lib/libmsgpackc.a (found suitable version "3.0.0", minimum required is "1.0.0") --- Found LibLUV: /usr/local/lib/libluv.dylib (Required is at least version "1.30.0") +-- Found LibLUV: /Users/dhruvmanilawala/contributing/neovim/.deps/usr/lib/libluv_a.a (Required is at least version "1.30.0") -- Found TreeSitter 0.6.3
So,
brew uninstall luvfixes the issue.Reacted by Ronnie Magatti and kloojReacted by Ronnie MagattiYes, I can reproduce that. This should not happen -- the build should never pick up system libraries unless you set
BUNDLED=OFF. And if it does, it should also pick up the corresponding system LibUV (it's the mismatch that's the problem, I assume).@jamessan do you know what could be wrong with the CMake scripts here?
So,
brew uninstall luvfixes the issue.If you want to keep the brew install of nvim working then
brew unlink luvalso seems to do the trick.Reacted by Garrett GeorgeI ran into the exact same problem recently and the fix was the same: NixOS/nixpkgs#132433
I used
objdump -pto see which libraries the binary was loading at runtime and noticed that some libraries were coming from different sources.I am not a Cmake expert, but here is what I've found.
When using the bundled dependencies, libluv gets built as a static library to
.deps/usr/lib/libluv_a.a. Notice the_asuffix. This seems to be the reason that Cmake is preferring the system installation oflibluvif present. If I manually remove that_asuffix and rename the file to.deps/usr/lib/libluv.athen Cmake correctly picks up the bundled version of libluv, even with a system version present.Reacted by Christian ClasonOkay I think I figured out the issue.
Here is the relevant log output with
CMAKE_FIND_DEBUG_MODEenabled:CMake Debug Log at cmake/FindLibLUV.cmake:20 (find_library): find_library called with the following settings: VAR: LIBLUV_LIBRARY NAMES: "luv" "luv_a" "libluv_a" "luv.dylib" Documentation: Path to a library. Framework Only Search Frameworks: 0 Search Frameworks Last: 0 Search Frameworks First: 1 AppBundle Only Search AppBundle: 0 Search AppBundle Last: 0 Search AppBundle First: 1 CMAKE_FIND_USE_CMAKE_PATH: 1 CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH: 1 CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH: 1 CMAKE_FIND_USE_CMAKE_SYSTEM_PATH: 1 find_library considered the following locations: /Users/andg/src/neovim/.deps/usr/lib/(lib)luv(\.tbd|\.dylib|\.so|\.a) /Users/andg/src/neovim/.deps/usr/(lib)luv(\.tbd|\.dylib|\.so|\.a) /Users/andg/.local/bin/(lib)luv(\.tbd|\.dylib|\.so|\.a) /opt/homebrew/bin/(lib)luv(\.tbd|\.dylib|\.so|\.a) /opt/homebrew/sbin/(lib)luv(\.tbd|\.dylib|\.so|\.a) /usr/bin/(lib)luv(\.tbd|\.dylib|\.so|\.a) /bin/(lib)luv(\.tbd|\.dylib|\.so|\.a) /usr/sbin/(lib)luv(\.tbd|\.dylib|\.so|\.a) /sbin/(lib)luv(\.tbd|\.dylib|\.so|\.a) /Applications/VMware Fusion.app/Contents/Public/(lib)luv(\.tbd|\.dylib|\.so|\.a) /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib/(lib)luv(\.tbd|\.dylib|\.so|\.a) /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/(lib)luv(\.tbd|\.dylib|\.so|\.a) The item was found at /opt/homebrew/lib/libluv.dylibluv_ais indeed listed under names, but becauseluvis listed first CMake first searches all paths for alibluvlibrary, which it finds under/opt/homebrew(or elsewhere on the system). If we swap the order in the CMake file and putluv_abeforeluv, then it correctly finds the bundled dependency first before looking for system libraries.Reacted by Christian Clason and Justin M. KeyesReacted by Christian Clason, Dhruv Manilawala and Justin M. KeyesThat's precisely where I was at, too, but that didn't seem to work for me. Let me test again.
EDIT Wrong clone 🤦🏻 (Curse you, frecency, for stabbing me in the back thusly!)
Yep, works.
Do you want to do the honors and PR that change?
Reacted by Gregory Anders and Timothy Schwarz
nvim --version: (from good commit)nvim --version: (from bad commit)$TERM:tmux-256colorxterm-kittySteps to reproduce using
git bisectNeovim exits with
Abort trap: 6from this commit 3de777d which was found usinggit bisectfrom 79fe9de (bad commit) torelease-0.5(good commit).NOTE: Using
brew install --HEAD neovimworks on the latest master.Stacktrace
From the first bad commit 3de777d