Comments (8)
NVIM v0.9.4
try Nvim 0.10 (development prerelease). The Releases page has pre-built archives for Linux/Windows/macOS.
from luv.
We need more Info, if you can, please do that.
-
nvim -v
tell nvim version -
nvim --cmd "lua print(vim.loop.version_string())"
tell luv version -
and please describe how to reproduce this.
from luv.
We need more Info, if you can, please do that.
nvim -v
tell nvim version
NVIM v0.9.4
Build type: Release
LuaJIT 2.1.1693350652
nvim --cmd "lua print(vim.loop.version_string())"
tell luv version
1.48.0
- 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
from luv.
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 ?? ()
from luv.
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 ?
from luv.
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.
from luv.
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
from luv.
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 ?? ()
from luv.
Related Issues (20)
- track issues in neovim related with luv HOT 4
- CI failing for LuaJIT v2.1 branch
- process creation segfault HOT 2
- How to pass command line string to uv.spawn? HOT 4
- Do I have to use `uv.run()` to wait async reading file with `fs_read` API? HOT 2
- Question: Is `shutdown` and `close` (use new_pipe with spawn) sync or async? HOT 1
- Question: the arrival order of uv.spawn `on_exit` and `data == nil` in `read_start` callback on Windows 10? HOT 2
- Why udp_recv_start callback call twice? HOT 2
- `tty normal` normal tests fails for me on Fedora mockbuild HOT 4
- Error loading module luv HOT 3
- Unable to send handles with uv_write2
- UBSan is detecting problems but not failing the CI
- Importance of case for signal names (and other names) HOT 1
- Flaky UDP test in CI HOT 3
- A test failure while building luv in mock for Amazon Linux 2023
- Lua 5.4.7 update HOT 4
- callbacks for signal_start and signal_start_oneshot should receive a number HOT 9
- atexit() is probably not a good way to clean up Lua VM HOT 2
- Add important 'Requires' fields to pc file
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from luv.