Skip to content
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.

Sign up for GitHub

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

Jump to bottom

luv_handle_gc segfault (from neovim) #701

Open
Tracked by #663
xlfe opened this issue Apr 25, 2024 · 8 comments
Open
Tracked by #663

luv_handle_gc segfault (from neovim) #701

xlfe opened this issue Apr 25, 2024 · 8 comments
Labels
bug

Comments

@xlfe
Copy link

xlfe commented Apr 25, 2024

Describe the bug

When running neovim I regularly (somewhere between once every 30 minutes and 3 times in a minute or two) get a segfault which kills neovim.

Backtrace shows something with libluv


        Signal: 11 (SEGV)
     Timestamp: Wed 2024-04-24 22:38:51 AEST (29s ago)
  Command Line: /nix/store/xcldy06fxypbpbnlnrwmqr8rpyr2fpkp-neovim-0.9.4/bin/nvim --embed -u /nix/store/vh3w2vxh9mi7rryii8rrxn256nzhr047-init.vim --cmd $'lua vim.g.loaded_node_provider=0;vim.g.loaded_perl_provider=0;vim.g.loaded_python_provider=0;vim.g.python3_host_prog=\'/nix/store/xcldy06fxypbpbnlnrwmqr8rpyr2fpkp-neovim-0.9.4/bin/nvim-python3\';vim.g.loaded_ruby_provider=0' --cmd $'set packpath^=/nix/store/jx41n9lxf9l3msx72ri16jwmk245bnva-vim-pack-dir' --cmd $'set rtp^=/nix/store/jx41n9lxf9l3msx72ri16jwmk245bnva-vim-pack-dir'
    Executable: /nix/store/ikvvv0hfxhgmzxnp3kww6yzql7y3prdn-neovim-unwrapped-0.9.4/bin/nvim
       Message: Process 205658 (nvim) of user dumped core.
                
                Module libparinfer_rust.so without build-id.
                Module clojure.so without build-id.
                Module libstdc++.so.6 without build-id.
                Module libgcc_s.so.1 without build-id.
                Module libluajit-5.1.so.2 without build-id.
                Module libunibilium.so.4 without build-id.
                Module libtree-sitter.so.0 without build-id.
                Module libmsgpack-c.so.2 without build-id.
                Module libvterm.so.0 without build-id.
                Module libtermkey.so.1 without build-id.
                Module libluv.so.1 without build-id.
                Module libclang_rt.scudo-x86_64.so without build-id.
                Stack trace of thread 205658:
                #0  0x00007fca16fe581e uw_frame_state_for (libgcc_s.so.1 + 0x1681e)
                #1  0x00007fca16fe757b _Unwind_Backtrace (libgcc_s.so.1 + 0x1857b)
                #2  0x00007fca16851c43 __backtrace (libc.so.6 + 0x11ac43)
                #3  0x00007fca16a20b79 _ZN12_GLOBAL__N_19BacktraceEPmm (libclang_rt.scudo-x86_64.so + 0x20b79)
                #4  0x00007fca16a1efa5 _ZN8gwp_asan18AllocationMetadata12CallSiteInfo15RecordBacktraceEPFmPmmE (libclang_rt.scudo-x86_64.so + 0x1efa5)
                #5  0x00007fca16a1fe34 _ZN8gwp_asan20GuardedPoolAllocator10deallocateEPv (libclang_rt.scudo-x86_64.so + 0x1fe34)
                #6  0x00007fca1714286a luv_handle_gc (libluv.so.1 + 0xb86a)
                #7  0x00007fca17042a36 n/a (libluajit-5.1.so.2 + 0xba36)
                #8  0x00007fca17089de7 n/a (libluajit-5.1.so.2 + 0x52de7)
                #9  0x00007fca1708a0d8 n/a (libluajit-5.1.so.2 + 0x530d8)
                #10 0x00007fca1708a6c5 n/a (libluajit-5.1.so.2 + 0x536c5)
                #11 0x00007fca1709fcc1 n/a (libluajit-5.1.so.2 + 0x68cc1)
                #12 0x00007fca17044a19 n/a (libluajit-5.1.so.2 + 0xda19)
                #13 0x0000200000000020 n/a (n/a + 0x0)
                ELF object binary architecture: AMD x86-64
@squeek502 squeek502 added the bug label Apr 25, 2024
@zhaozg
Copy link
Member

zhaozg commented Apr 25, 2024 •
edited
Loading

We need more Info, if you can, please do that.

  1. nvim -v tell nvim version

  2. nvim --cmd "lua print(vim.loop.version_string())" tell luv version

  3. and please describe how to reproduce this.

@xlfe
Copy link
Author

xlfe commented Apr 25, 2024

We need more Info, if you can, please do that.

  1. nvim -v tell nvim version

NVIM v0.9.4
Build type: Release
LuaJIT 2.1.1693350652

  1. nvim --cmd "lua print(vim.loop.version_string())" tell luv version

1.48.0

  1. and please describe how to reproduce this.

I don't have a reliable reproduction sorry, it seems to happen randomly - but it's pretty consistent - a few times per hour

@zhaozg zhaozg mentioned this issue Apr 25, 2024
Open
3 tasks
@justinmk
Copy link

NVIM v0.9.4

try Nvim 0.10 (development prerelease). The Releases page has pre-built archives for Linux/Windows/macOS.

@xlfe
Copy link
Author

xlfe commented Apr 27, 2024

Still happens on NVIM v0.10.0-dev-435dee7

(gdb) thread apply all bt

Thread 5 (LWP 72373):
#0  0x00006cf49faf7c5e in __futex_abstimed_wait_common () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#1  0x00006cf49fafa4c0 in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#2  0x00006cf49fc79569 in uv_cond_wait () from /nix/store/m5hi3j55l2l2yvsa2vz0p0il60vznz90-libuv-1.48.0/lib/libuv.so.1
#3  0x00006cf49fc666ae in worker () from /nix/store/m5hi3j55l2l2yvsa2vz0p0il60vznz90-libuv-1.48.0/lib/libuv.so.1
#4  0x00006cf49fafb272 in start_thread () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#5  0x00006cf49fb76dcc in clone3 () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6

Thread 4 (LWP 72375):
#0  0x00006cf49faf7c5e in __futex_abstimed_wait_common () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#1  0x00006cf49fafa4c0 in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#2  0x00006cf49fc79569 in uv_cond_wait () from /nix/store/m5hi3j55l2l2yvsa2vz0p0il60vznz90-libuv-1.48.0/lib/libuv.so.1
#3  0x00006cf49fc666ae in worker () from /nix/store/m5hi3j55l2l2yvsa2vz0p0il60vznz90-libuv-1.48.0/lib/libuv.so.1
#4  0x00006cf49fafb272 in start_thread () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#5  0x00006cf49fb76dcc in clone3 () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6

Thread 3 (LWP 72374):
#0  0x00006cf49faf7c5e in __futex_abstimed_wait_common () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#1  0x00006cf49fafa4c0 in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#2  0x00006cf49fc79569 in uv_cond_wait () from /nix/store/m5hi3j55l2l2yvsa2vz0p0il60vznz90-libuv-1.48.0/lib/libuv.so.1
#3  0x00006cf49fc666ae in worker () from /nix/store/m5hi3j55l2l2yvsa2vz0p0il60vznz90-libuv-1.48.0/lib/libuv.so.1
#4  0x00006cf49fafb272 in start_thread () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#5  0x00006cf49fb76dcc in clone3 () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6

Thread 2 (LWP 72372):
#0  0x00006cf49faf7c5e in __futex_abstimed_wait_common () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#1  0x00006cf49fafa4c0 in pthread_cond_wait@@GLIBC_2.3.2 () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#2  0x00006cf49fc79569 in uv_cond_wait () from /nix/store/m5hi3j55l2l2yvsa2vz0p0il60vznz90-libuv-1.48.0/lib/libuv.so.1
#3  0x00006cf49fc666ae in worker () from /nix/store/m5hi3j55l2l2yvsa2vz0p0il60vznz90-libuv-1.48.0/lib/libuv.so.1
#4  0x00006cf49fafb272 in start_thread () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#5  0x00006cf49fb76dcc in clone3 () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6

Thread 1 (LWP 72353):
#0  0x00006cf49fa6281e in uw_frame_state_for () from /nix/store/hc0jij4wmrcdrad7fd381r4x2j12d550-gcc-12.3.0-lib/lib/libgcc_s.so.1
#1  0x00006cf49fa6457b in _Unwind_Backtrace () from /nix/store/hc0jij4wmrcdrad7fd381r4x2j12d550-gcc-12.3.0-lib/lib/libgcc_s.so.1
#2  0x00006cf49fb81c73 in backtrace () from /nix/store/35pq4hr29c3sl79lgfwgsvd9nwzyp4am-glibc-2.39-5/lib/libc.so.6
#3  0x00006cf49fe20b79 in (anonymous namespace)::Backtrace(unsigned long*, unsigned long) () from /nix/store/civcvh53r4h3g3797rpgkdafi2ibq04k-malloc-provider-scudo/lib/libclang_rt.scudo-x86_64.so
#4  0x00006cf49fe1efa5 in gwp_asan::AllocationMetadata::CallSiteInfo::RecordBacktrace(unsigned long (*)(unsigned long*, unsigned long)) () from /nix/store/civcvh53r4h3g3797rpgkdafi2ibq04k-malloc-provider-scudo/lib/libclang_rt.scudo-x86_64.so
#5  0x00006cf49fe1fe34 in gwp_asan::GuardedPoolAllocator::deallocate(void*) () from /nix/store/civcvh53r4h3g3797rpgkdafi2ibq04k-malloc-provider-scudo/lib/libclang_rt.scudo-x86_64.so
#6  0x00006cf4a042285a in luv_handle_gc () from /nix/store/v2m6bbgi0zxrhg2vk7gj25lhfrd18jiy-libluv-1.44.2-1/lib/libluv.so.1
#7  0x00006cf49fd7ca36 in ?? () from /nix/store/3m3ppqyz39ysm3qrxymxh09sd4zr6z1p-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#8  0x00006cf49fdc3fc7 in ?? () from /nix/store/3m3ppqyz39ysm3qrxymxh09sd4zr6z1p-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#9  0x00006cf49fdc42b8 in ?? () from /nix/store/3m3ppqyz39ysm3qrxymxh09sd4zr6z1p-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#10 0x00006cf49fdc48a5 in ?? () from /nix/store/3m3ppqyz39ysm3qrxymxh09sd4zr6z1p-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#11 0x00006cf49fdd9ff1 in ?? () from /nix/store/3m3ppqyz39ysm3qrxymxh09sd4zr6z1p-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#12 0x00006cf49fd7ea19 in ?? () from /nix/store/3m3ppqyz39ysm3qrxymxh09sd4zr6z1p-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#13 0x5946666656555857 in ?? ()
#14 0x59495f4666665f4e in ?? ()
#15 0x9999999999999999 in ?? ()
#16 0x2020202020202020 in ?? ()
#17 0x3ff0000000000000 in ?? ()
#18 0x4000000000000000 in ?? ()
#19 0x0000000000000000 in ?? ()

@xlfe
Copy link
Author

xlfe commented May 5, 2024

Anything else you need @zhaozg @justinmk - this is very annoying to have neovim crash regularly. Understand that's my problem not yours, but wondering if there's anything I could assist with in terms of debugging, etc ?

@squeek502
Copy link
Member

Do you have any plugins installed? If so, a list of your plugins would be helpful.

Unfortunately, luv_handle_gc can be called in a wide variety of scenarios (a handle is the base type of most libuv types), so it's difficult to narrow down the cause without being able to reproduce the problem.

@xlfe
Copy link
Author

xlfe commented May 5, 2024

Do you have any plugins installed? If so, a list of your plugins would be helpful.

Unfortunately, luv_handle_gc can be called in a wide variety of scenarios (a handle is the base type of most libuv types), so it's difficult to narrow down the cause without being able to reproduce the problem.

Okay fair - I'll try to put together a minimal reproducible example

@xlfe
Copy link
Author

xlfe commented May 6, 2024

Still trying to get a minimal reproducible example

I have lots of plugins installed, and I'm using Nix with the hardened profile which means instead of the normal glibc memory allocator, I'm using scudo

Just noticed this stacktrace has libtreesitter in it too

Thread 1 (Thread 0x67bc8aad3900 (LWP 172405)):
#0  0x000067bc8aaf381e in uw_frame_state_for () from /nix/store/hc0jij4wmrcdrad7fd381r4x2j12d550-gcc-12.3.0-lib/lib/libgcc_s.so.1
#1  0x000067bc8aaf557b in _Unwind_Backtrace () from /nix/store/hc0jij4wmrcdrad7fd381r4x2j12d550-gcc-12.3.0-lib/lib/libgcc_s.so.1
#2  0x000067bc8ac18c43 in backtrace () from /nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6
#3  0x000067bc8ae20b79 in (anonymous namespace)::Backtrace(unsigned long*, unsigned long) () from /nix/store/civcvh53r4h3g3797rpgkdafi2ibq04k-malloc-provider-scudo/lib/libclang_rt.scudo-x86_64.so
#4  0x000067bc8ae1efa5 in gwp_asan::AllocationMetadata::CallSiteInfo::RecordBacktrace(unsigned long (*)(unsigned long*, unsigned long)) () from /nix/store/civcvh53r4h3g3797rpgkdafi2ibq04k-malloc-provider-scudo/lib/libclang_rt.scudo-x86_64.so
#5  0x000067bc8ae1fe34 in gwp_asan::GuardedPoolAllocator::deallocate(void*) () from /nix/store/civcvh53r4h3g3797rpgkdafi2ibq04k-malloc-provider-scudo/lib/libclang_rt.scudo-x86_64.so
#6  0x000067bc8b447aa3 in ts_subtree_release () from /nix/store/mxvi52xmlhs7dz1nww17mdwl3i03w5ps-tree-sitter-0.20.8/lib/libtree-sitter.so.0
#7  0x000067bc8b449176 in ts_tree_delete () from /nix/store/mxvi52xmlhs7dz1nww17mdwl3i03w5ps-tree-sitter-0.20.8/lib/libtree-sitter.so.0
#8  0x00000000005bcb62 in tree_gc ()
#9  0x000067bc8b389a36 in ?? () from /nix/store/08lab32sarzg4jp2ms8kzvk1g181ba7z-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#10 0x000067bc8b3d0de7 in ?? () from /nix/store/08lab32sarzg4jp2ms8kzvk1g181ba7z-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#11 0x000067bc8b3d10d8 in ?? () from /nix/store/08lab32sarzg4jp2ms8kzvk1g181ba7z-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#12 0x000067bc8b3d16c5 in ?? () from /nix/store/08lab32sarzg4jp2ms8kzvk1g181ba7z-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#13 0x000067bc8b3e6cc1 in ?? () from /nix/store/08lab32sarzg4jp2ms8kzvk1g181ba7z-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#14 0x000067bc8b38ba19 in ?? () from /nix/store/08lab32sarzg4jp2ms8kzvk1g181ba7z-luajit-2.1.1693350652-env/lib/libluajit-5.1.so.2
#15 0xffffffffffff0000 in ?? ()
#16 0x0000000000000000 in ?? ()

@xlfe xlfe mentioned this issue May 10, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@zhaozg @xlfe @justinmk @squeek502