Winit: Application fails to start under XMonad

[chrisduerr]

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

[kurnevsky]

the application just aborts without printing anything

It actually just hangs, not aborts.

[murarth]

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.

[murarth]

I've submitted PR #1475 to fix the deadlock.

@kurnevsky Can you confirm that the deadlock is fixed? Also, if winit now aborts with an error, that would be helpful in addressing the underlying issue here.

[kurnevsky]

It fixes the problem, and cargo run --example window creates the window now when it hangs on master branch. In the logs I see the following error (but it doesn't affect launching):

2020-02-19 00:19:11,599 ERROR [winit::platform_impl::platform] X11 error: XError {
    description: "BadWindow (invalid Window parameter)",
    error_code: 3,
    request_code: 20,
    minor_code: 0,
}

[murarth]

@kurnevsky That error is not as helpful as I had hoped it would be. Could you run xtrace -n cargo run --example window and post the output?

[kurnevsky]

My xtrace doesn't have -n option. When running as xtrace /bin/cargo run --example window it doesn't print any call, just empty table...

[kurnevsky]

strace output:
out.txt

[LadyBoonami]

This is a trap I also fell into recently. There are actually two programs called xtrace:

• One of them belongs to glibc, it is a shell script that executes a program and dumps every function call to a separate xterm window. To my knowledge it relies on DWARF debug information to do its job, without that it won't work.
• The other one is a standalone program, found at https://salsa.debian.org/debian/xtrace . It executes a program and dumps all the message exchange between X client and X server to stderr. To avoid collisions, the executable is renamed to x11trace on gentoo.

I assume that @murarth meant the second one, while @kurnevsky failed to get meaningful output out of the first. As I also have the same issue, I'd love to contribute my logs, but I cannot seem to reproduce it reliably.

[kurnevsky]

Tried x11trace but it fails with:

Got connection from unknown(local)
000:<: am lsb-first want 11:0 authorising with '' of length 0
000:>: Failed, version is 11:0 reason is '  No protocol specified
'.
No protocol specified
thread 'main' panicked at 'Failed to initialize any backend! Wayland status: NoCompositorListening X11 status: XOpenDisplayFailed', src/platform_impl/linux/mod.rs:567:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[artursapek]

@kurnevsky I just started getting this same error in an application using winit, and restarting my machine resolved it. super strange. I'll see if I can figure out how to reproduce it.

[kurnevsky]

I can reproduce it consistently so if anyone have ideas - I can test them :)

btw, with last winit version it works fine, just prints error in logs.

[chrisduerr]

@kurnevsky What do you mean by last winit version? 0.21.0? Because the bug was reported before 0.22.0 was released.

[kurnevsky]

I mean the version 0.22 doesn't hang anymore.

[chrisduerr]

@kurnevsky Alacritty's latest version should use version 0.22. Does that mean you cannot reproduce it with Alacritty anymore?

That just sounds to me like the bug has been fixed and both winit's and Alacritty's issues should be closed.

[kurnevsky]

It's not solved completely as now instead of hanging it writes an error in logs in this case. I think alacritty issue can be closed but I'd left this one open.

[chrisduerr]

It's not solved completely as now instead of hanging it writes an error in logs in this case.

Is there any functional problem resulting from this?

[kurnevsky]

I didn't observe any.