alacritty: Panic on screen unlock
Sometimes when I resume/unlock my laptop, alacritty crashes with the panic below.
Which operating system does the issue occur on? Fedora 29 x86_64 I’ve built alacritty from version 9ba7c4fae4d927e109c7981f7e11ca7acdc14eb3.
If on linux, are you using X11 or Wayland? Wayland (Gnome 3.30.2)
wl_registry@2: error 0: invalid global wl_output (39)
thread 'main' panicked at 'Wayland connection lost.: Os { code: 71, kind: Other, message: "Protocol error" }', src/libcore/result.rs:997:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
1: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:70
2: std::panicking::default_hook::{{closure}}
at src/libstd/sys_common/backtrace.rs:58
at src/libstd/panicking.rs:200
3: std::panicking::default_hook
at src/libstd/panicking.rs:215
4: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:478
5: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:385
6: rust_begin_unwind
at src/libstd/panicking.rs:312
7: core::panicking::panic_fmt
at src/libcore/panicking.rs:85
8: core::result::unwrap_failed
at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/libcore/macros.rs:16
9: <core::result::Result<T, E>>::expect
at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/libcore/result.rs:825
10: winit::platform::platform::wayland::event_loop::EventsLoop::poll_events
at ./.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.18.1/src/platform/linux/wayland/event_loop.rs:169
11: winit::platform::platform::EventsLoop::poll_events
at ./.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.18.1/src/platform/linux/mod.rs:504
12: winit::EventsLoop::poll_events
at ./.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.18.1/src/lib.rs:273
13: alacritty::window::Window::poll_events
at ./src/3rd-party/alacritty/src/window.rs:208
14: <alacritty::event::Processor<N>>::process_events
at ./src/3rd-party/alacritty/src/event.rs:536
15: alacritty::run
at src/main.rs:221
16: alacritty::main
at src/main.rs:102
17: std::rt::lang_start::{{closure}}
at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/libstd/rt.rs:64
18: std::panicking::try::do_call
at src/libstd/rt.rs:49
at src/libstd/panicking.rs:297
19: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:92
20: std::rt::lang_start_internal
at src/libstd/panicking.rs:276
at src/libstd/panic.rs:388
at src/libstd/rt.rs:48
21: std::rt::lang_start
at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/libstd/rt.rs:64
22: main
23: __libc_start_main
24: _start
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 22 (14 by maintainers)
I interpret this as alacritty crashing as a consequence of sway crashing, rather than the other way around.
In any case, if sway crashes, then there is a sway bug worth reporting to them. An ill-behaving wayland client should not be able to crash the compositor.
If sway crashing for you, it’s a sway bug.
According to the exchanges that occured upstream about this issue ( see https://gitlab.freedesktop.org/wayland/wayland/issues/10 ), there is no good solution currently, except notifying Gnome about this issue so that they stop creating then deleting
wl_ouputglobals in a short timespan.Are you running sway master + wlroots master? If not , please, try to repro on them. And also our master.
Some (but not all) of my Alacritty instances are crashing on Sway from time to time when I focus them (they basically crash instantly after I switch to them). Unfortunately I didn’t find a way to reproduce these crashes yet 😮
Example console outputs from my last few Alacritty crashes:
Unfortunately I didn’t use
WAYLAND_DEBUGandRUST_BACKTRACEwhen those crashes occurred.Regarding my setup: At least the last crash was with Alacritty 0.4.2, Sway 1.4, Wayland 1.18, and
wayland-protocols1.20.Update: I just lost all Alacritty terminals on one of my Sway workspaces. This is unfortunately getting SUPER frustrating, I might have to switch to the X11/XWayland backend 😮
Backtraces:
@nixpulvis I read this sentence as sway crashing. If we also crashed during its crash I don’t mind this crash. As you can see an issue that connection to sway was lost.
If we crash after screen unlock but everything else continues to run, then it’s our issue.
@kchibisov
thread 'main' panicked at 'Wayland connection lost.doesn’t look like a sway crash to me. So while sway shouldn’t crash, it’s seemingly caused by a crash in alacritty, which also shouldn’t happen.@blitz Can you verify if this is still broken? The upstream issue is closed, but I don’t think this is resolved yet.
So I guess this is tracked upstream in https://github.com/Smithay/wayland-rs/issues/203 now.
This is a hard program crash, so there’s no way to just ignore it.
However you might have some success trying to launch it using XWayland, you can do that by running Alacritty with
WAYLAND_DISPLAY= alacritty.Could you reproduce this while running the winit example with the env variable
WAYLAND_DEBUG=1and provide the log here?Upstream issue: https://github.com/tomaka/winit/issues/705