vhakulinen / gnvim

GUI for neovim, without any web bloat
MIT License
1.84k stars 69 forks source link

Sometimes prints panic message on startup #209

Open linuxtim opened 1 year ago

linuxtim commented 1 year ago

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.
vhakulinen commented 1 year ago

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.

tim-seoss commented 1 year ago

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?

vhakulinen commented 1 year ago

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.

vhakulinen commented 1 year ago

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:

  1. 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_attach call.
  2. Make sure the ui_attach happens 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.