gnvim
gnvim copied to clipboard
Sometimes prints panic message on startup
Firstly, thanks very much for writing gnvim... I thought I'd give it a try, so after compilation and installation, I tried starting it from the command line and got a panic.
I compiled and I'm running on on Debian 12 amd64, under Wayland (I haven't tried other environments), and the panic occurs on approx 50% of invocations, the following is printed on startup:
RUST_BACKTRACE=1 gnvim
thread 'main' panicked at 'nvim_ui_try_resize failed: Error(Array([Integer(PosInt(0)), String(Utf8String { s: Ok("UI not attached to channel: 1") })]))', ui/src/components/shell/mod.rs:71:31
stack backtrace:
0: rust_begin_unwind
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:579:5
1: core::panicking::panic_fmt
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:64:14
2: core::result::unwrap_failed
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/result.rs:1750:5
3: core::result::Result<T,E>::expect
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/result.rs:1047:23
4: gnvim::components::shell::Shell::resize_nvim::{{closure}}::{{closure}}
at ./ui/src/components/shell/mod.rs:71:21
5: glib::main_context_futures::<impl glib::auto::main_context::MainContext>::spawn_local_with_priority::{{closure}}
at /home/tim/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.17.5/src/main_context_futures.rs:564:23
6: <futures_task::future_obj::LocalFutureObj<T> as core::future::future::Future>::poll
at /home/tim/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-task-0.3.27/src/future_obj.rs:84:18
7: <glib::main_context_futures::FutureWrapper as core::future::future::Future>::poll
at /home/tim/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.17.5/src/main_context_futures.rs:38:68
8: glib::main_context_futures::TaskSource::poll::{{closure}}::{{closure}}
at /home/tim/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.17.5/src/main_context_futures.rs:245:25
9: core::ops::function::FnOnce::call_once
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/ops/function.rs:250:5
10: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panic/unwind_safe.rs:271:9
11: std::panicking::try::do_call
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:487:40
12: std::panicking::try
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:451:19
13: std::panic::catch_unwind
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panic.rs:140:14
14: glib::main_context_futures::TaskSource::poll::{{closure}}
at /home/tim/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.17.5/src/main_context_futures.rs:244:31
15: glib::main_context::<impl glib::auto::main_context::MainContext>::with_thread_default
at /home/tim/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.17.5/src/main_context.rs:154:12
16: glib::main_context_futures::TaskSource::poll
at /home/tim/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.17.5/src/main_context_futures.rs:236:9
17: glib::main_context_futures::TaskSource::dispatch
at /home/tim/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.17.5/src/main_context_futures.rs:74:34
18: g_main_context_dispatch
19: <unknown>
20: g_main_context_iteration
21: g_application_run
22: <O as gio::application::ApplicationExtManual>::run_with_args
at /home/tim/.cargo/registry/src/github.com-1ecc6299db9ec823/gio-0.17.4/src/application.rs:37:13
23: gnvim::main
at ./ui/src/main.rs:41:5
24: core::ops::function::FnOnce::call_once
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Which nvim version are you using? And by any chance are you using a window manager that automatically modifies the window size (tiling wm)? Looks like gnvim is trying to report a updated window size to neovim before the ui_attach call.
neovim versions 0.9.0 and also with 0.9.1-pre (built from release-0.9 branch 3 days ago). I'm using KDE (including KDE's kwin window manager) under Wayland. I suppose it might be modifying the window size (to replicate the dimensions that gnvim had on its last invocation), although I don't see this occurring. If it would be helpful I can try and get some debug info out of kwin?
Window manager modifying the window size was just a hunch. It doesn't (or shouldn't) matter if that happens or not - its still a bug in gnvim.
I haven't encountered this issue earlier, but it might be a race condition between this code and everything else that is communicating with neovim.
I flattened the rpc client stuff to make its usage a bit more straightforward, and now fixing this should be just a matter of implementing either:
- Some sort of queue for the rpc calls. The current mutex used for the rpc writer isn't FIFO. The queue could just be used before the
ui_attachcall. - Make sure the
ui_attachhappens before the rpc object is given forward to other components.
I still haven't encountered this issue myself, hence my personal priority for fixing this isn't the highest. I'm happy to accept any PRs.