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.

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

Sometimes prints panic message on startup #209

Open
linuxtim opened this issue May 21, 2023 · 4 comments
Open

Sometimes prints panic message on startup #209

linuxtim opened this issue May 21, 2023 · 4 comments

Comments

@linuxtim
Copy link

linuxtim commented May 21, 2023

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
Copy link
Owner

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
Copy link
Contributor

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
Copy link
Owner

vhakulinen commented Jun 3, 2023

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants