winit: Application fails to start under XMonad

This was originally reported to Alacritty in https://github.com/alacritty/alacritty/issues/3348.

It seems like after some time, or when XMonad is restarted, it is not possible to launch winit based applications anymore.

The backtrace seems to suggest that querying for the wm name fails. It’s noteworthy that this does not actually cause a Rust panic, but instead the application just aborts without printing anything.

Backtrace
#0  0x00007f33bba33f8d in syscall () from /usr/lib/libc.so.6
#1  0x000055ecaf0bf7a0 in parking_lot_core::thread_parker::imp::ThreadParker::futex_wait (self=0x7f33bb488790, ts=...)
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot_core-0.7.0/src/thread_parker/linux.rs:111
#2  0x000055ecaf0bf4ca in <parking_lot_core::thread_parker::imp::ThreadParker as parking_lot_core::thread_parker::ThreadParkerT>::park (self=0x7f33bb488790)
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot_core-0.7.0/src/thread_parker/linux.rs:65
#3  0x000055ecaf0becd9 in parking_lot_core::parking_lot::park::{{closure}} (thread_data=0x7f33bb488770)
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot_core-0.7.0/src/parking_lot.rs:611
#4  0x000055ecaf0be95f in parking_lot_core::parking_lot::with_thread_data (f=...)
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot_core-0.7.0/src/parking_lot.rs:183
#5  parking_lot_core::parking_lot::park (key=94475042771272, validate=..., before_sleep=..., timed_out=..., park_token=..., timeout=...)
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot_core-0.7.0/src/parking_lot.rs:576
#6  0x000055ecaf0bdc2a in parking_lot::raw_mutex::RawMutex::lock_slow (
    self=0x55ecaf5d5148 <<winit::platform_impl::platform::X11_BACKEND as core::ops::deref::Deref>::deref::__stability::LAZY>, timeout=...)
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot-0.10.0/src/raw_mutex.rs:256
#7  0x000055ecaee89979 in <parking_lot::raw_mutex::RawMutex as lock_api::mutex::RawMutex>::lock (
    self=0x55ecaf5d5148 <<winit::platform_impl::platform::X11_BACKEND as core::ops::deref::Deref>::deref::__stability::LAZY>)
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot-0.10.0/src/raw_mutex.rs:72
#8  0x000055ecaedf9916 in lock_api::mutex::Mutex<R,T>::lock (self=0x55ecaf5d5148 <<winit::platform_impl::platform::X11_BACKEND as core::ops::deref::Deref>::deref::__stability::LAZY>)
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/lock_api-0.3.3/src/mutex.rs:156
#9  0x000055ecaedb034d in winit::platform_impl::platform::x_error_callback (display=0x55ecafbadfc0, event=0x7ffe0c9820a0)
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.21.0/src/platform_impl/linux/mod.rs:480
#10 0x00007f33bb3335db in _XError () from /usr/lib/libX11.so.6
#11 0x00007f33bb330388 in ?? () from /usr/lib/libX11.so.6
#12 0x00007f33bb331586 in _XReply () from /usr/lib/libX11.so.6
#13 0x00007f33bb316db6 in XGetWindowProperty () from /usr/lib/libX11.so.6
#14 0x000055ecaedacc93 in winit::platform_impl::platform::x11::util::window_property::<impl winit::platform_impl::platform::x11::xdisplay::XConnection>::get_property (self=0x55ecafbbb650,
    window=23068673, property=458, property_type=33) at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.21.0/src/platform_impl/linux/x11/util/window_property.rs:55
#15 0x000055ecaedae70a in winit::platform_impl::platform::x11::util::wm::<impl winit::platform_impl::platform::x11::xdisplay::XConnection>::get_wm_name (self=0x55ecafbbb650, root=349)
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.21.0/src/platform_impl/linux/x11/util/wm.rs:75
#16 0x000055ecaedae335 in winit::platform_impl::platform::x11::util::wm::<impl winit::platform_impl::platform::x11::xdisplay::XConnection>::update_cached_wm_info (self=0x55ecafbbb650,
    root=349) at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.21.0/src/platform_impl/linux/x11/util/wm.rs:26
#17 0x000055ecae59a61c in winit::platform_impl::platform::x11::EventLoop<T>::new (xconn=...)
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.21.0/src/platform_impl/linux/x11/mod.rs:156
#18 0x000055ecae4d4dda in core::ops::function::FnOnce::call_once () at /build/rust/src/rustc-1.41.0-src/src/libcore/ops/function.rs:232
#19 0x000055ecae579e46 in core::result::Result<T,E>::map (self=..., op=0x55ecaee15e55 <core::cell::Cell<T>::set+117>) at /build/rust/src/rustc-1.41.0-src/src/libcore/result.rs:512
#20 0x000055ecae594d14 in winit::platform_impl::platform::EventLoop<T>::new_x11_any_thread ()
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.21.0/src/platform_impl/linux/mod.rs:587
#21 0x000055ecae594a17 in winit::platform_impl::platform::EventLoop<T>::new_any_thread ()
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.21.0/src/platform_impl/linux/mod.rs:558
#22 0x000055ecae594e10 in winit::platform_impl::platform::EventLoop<T>::new ()
    at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.21.0/src/platform_impl/linux/mod.rs:531
#23 0x000055ecae498861 in winit::event_loop::EventLoop<T>::with_user_event () at /home/kurnevsky/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.21.0/src/event_loop.rs:128
#24 0x000055ecae46cc56 in alacritty::main () at alacritty/src/main.rs:87

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Comments: 19 (6 by maintainers)

Most upvoted comments

Looking at the backtrace, it looks like a simple deadlock. The static value X11_BACKEND is a Mutex, which is acquired for the duration of EventLoop::new_x11_any_thread and acquired again in x_error_callback. The fix should be quite straightforward. I’ll submit a PR shortly.

Of course, once the deadlock is solved, there’s still the underlying issue of why X is giving an error in this case, but we’ll deal with that when we get there.

the application just aborts without printing anything

It actually just hangs, not aborts.