winit
winit copied to clipboard
rust-windowing
"internal error: entered unreachable code" when using Wayland backend
Attempting to create a Window on the Wayland backend on my system results in the following:
thread 'main' panicked at 'internal error: entered unreachable code', /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.23.0/src/platform_impl/linux/wayland/window/mod.rs:218:77
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[wayland-client error] A handler for wl_keyboard panicked.
Which seems to be coming from this:
// To make our window usable for drawing right away we must `ack` a `configure`
// from the server, the acking part here is done by SCTK window frame, so we just
// need to sync with server so it'll be done automatically for us.
event_loop_handle.with_source(&wayland_source, |event_queue| {
let event_queue = event_queue.queue();
let _ = event_queue.sync_roundtrip(&mut *winit_state, |_, _, _| unreachable!());
});
Can anyone explain what this little piece of code is doing and what would cause the it to be reachable?
Some object that was created wasn't assigned to a queue. Could you share a code and WAYLAND_DEBUG=1 output?
Oh, do you have libxkbcommon installed and also on which distro are you on? IIRC you can only reach that code if we failed to open libxkbcommon or something like that.
Well I didn't expect a response in <5 minutes...
First off, here is the RUST_BACKTRACE=1 I meant to add:
thread 'main' panicked at 'internal error: entered unreachable code', /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.23.0/src/platform_impl/linux/wayland/window/mod.rs:220:17
stack backtrace:
0: std::panicking::begin_panic
at /rustc/2d8a3b9181f41d3af9b9f016c5d73b2553e344bf/library/std/src/panicking.rs:497
1: winit::platform_impl::platform::wayland::window::Window::new::{{closure}}::{{closure}}
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.23.0/src/platform_impl/linux/wayland/window/mod.rs:220
2: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
at /rustc/2d8a3b9181f41d3af9b9f016c5d73b2553e344bf/library/core/src/ops/function.rs:269
3: wayland_client::imp::proxy::proxy_dispatcher::{{closure}}::{{closure}}
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.28.1/src/native_lib/proxy.rs:412
4: scoped_tls::ScopedKey<T>::with
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:171
5: wayland_client::imp::proxy::proxy_dispatcher::{{closure}}
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.28.1/src/native_lib/proxy.rs:409
6: std::panicking::try::do_call
at /rustc/2d8a3b9181f41d3af9b9f016c5d73b2553e344bf/library/std/src/panicking.rs:373
7: __rust_try
8: std::panicking::try
at /rustc/2d8a3b9181f41d3af9b9f016c5d73b2553e344bf/library/std/src/panicking.rs:337
9: std::panic::catch_unwind
at /rustc/2d8a3b9181f41d3af9b9f016c5d73b2553e344bf/library/std/src/panic.rs:379
10: wayland_client::imp::proxy::proxy_dispatcher
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.28.1/src/native_lib/proxy.rs:376
11: wl_closure_dispatch
12: dispatch_event.isra.0
13: wl_display_dispatch_queue_pending
14: wl_display_roundtrip_queue
15: wayland_client::imp::event_queue::EventQueueInner::sync_roundtrip::{{closure}}
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.28.1/src/native_lib/event_queue.rs:86
16: wayland_client::imp::event_queue::with_dispatch_meta::{{closure}}
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.28.1/src/native_lib/event_queue.rs:24
17: scoped_tls::ScopedKey<T>::set
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:137
18: wayland_client::imp::event_queue::with_dispatch_meta
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.28.1/src/native_lib/event_queue.rs:24
19: wayland_client::imp::event_queue::EventQueueInner::sync_roundtrip
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.28.1/src/native_lib/event_queue.rs:84
20: wayland_client::event_queue::EventQueue::sync_roundtrip
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.28.1/src/event_queue.rs:191
21: winit::platform_impl::platform::wayland::window::Window::new::{{closure}}
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.23.0/src/platform_impl/linux/wayland/window/mod.rs:219
22: calloop::loop_logic::LoopHandle<Data>::with_source
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/calloop-0.6.5/src/loop_logic.rs:153
23: winit::platform_impl::platform::wayland::window::Window::new
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.23.0/src/platform_impl/linux/wayland/window/mod.rs:216
24: winit::platform_impl::platform::Window::new
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.23.0/src/platform_impl/linux/mod.rs:277
25: winit::window::WindowBuilder::build
at /home/slabity/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.23.0/src/window.rs:333
Here is what I have with WAYLAND_DEBUG=1:
[785450.456] -> [email protected]_registry(new id wl_registry@2)
[785450.482] -> [email protected](new id wl_callback@3)
[785450.543] [email protected]_id(3)
[785450.565] [email protected](1, "wl_shm", 1)
[785450.644] -> [email protected](1, "wl_shm", 1, new id [unknown]@4)
[785450.687] [email protected](2, "wl_drm", 2)
[785450.696] [email protected](3, "zwp_linux_dmabuf_v1", 3)
[785450.707] [email protected](4, "wl_compositor", 4)
[785450.723] -> [email protected](4, "wl_compositor", 4, new id [unknown]@5)
[785450.744] [email protected](5, "wl_subcompositor", 1)
[785450.758] -> [email protected](5, "wl_subcompositor", 1, new id [unknown]@6)
[785450.774] [email protected](6, "wl_data_device_manager", 3)
[785450.783] [email protected](7, "zwlr_gamma_control_manager_v1", 1)
[785450.796] [email protected](8, "gtk_primary_selection_device_manager", 1)
[785450.805] [email protected](9, "zxdg_output_manager_v1", 3)
[785450.820] [email protected](10, "org_kde_kwin_idle", 1)
[785450.833] [email protected](11, "zwp_idle_inhibit_manager_v1", 1)
[785450.846] [email protected](12, "zwlr_layer_shell_v1", 2)
[785450.854] [email protected](13, "xdg_wm_base", 2)
[785450.865] [email protected](14, "zwp_tablet_manager_v2", 1)
[785450.882] [email protected](15, "org_kde_kwin_server_decoration_manager", 1)
[785450.893] [email protected](16, "zxdg_decoration_manager_v1", 1)
[785450.913] -> [email protected](16, "zxdg_decoration_manager_v1", 1, new id [unknown]@7)
[785450.929] [email protected](17, "zwp_relative_pointer_manager_v1", 1)
[785450.944] -> [email protected](17, "zwp_relative_pointer_manager_v1", 1, new id [unknown]@8)
[785450.959] [email protected](18, "zwp_pointer_constraints_v1", 1)
[785450.975] -> [email protected](18, "zwp_pointer_constraints_v1", 1, new id [unknown]@9)
[785450.990] [email protected](19, "wp_presentation", 1)
[785451.002] [email protected](20, "zwlr_output_manager_v1", 1)
[785451.014] [email protected](21, "zwlr_output_power_manager_v1", 1)
[785451.028] [email protected](22, "zwp_input_method_manager_v2", 1)
[785451.039] [email protected](23, "zwp_text_input_manager_v3", 1)
[785451.055] -> [email protected](23, "zwp_text_input_manager_v3", 1, new id [unknown]@10)
[785451.071] [email protected](24, "zwlr_foreign_toplevel_manager_v1", 2)
[785451.084] [email protected](25, "zwlr_export_dmabuf_manager_v1", 1)
[785451.094] [email protected](26, "zwlr_screencopy_manager_v1", 3)
[785451.106] [email protected](27, "zwlr_data_control_manager_v1", 2)
[785451.114] [email protected](28, "zwp_primary_selection_device_manager_v1", 1)
[785451.124] [email protected](29, "wp_viewporter", 1)
[785451.132] [email protected](30, "zwp_virtual_keyboard_manager_v1", 1)
[785451.142] [email protected](31, "zwlr_virtual_pointer_manager_v1", 2)
[785451.151] [email protected](32, "zwlr_input_inhibit_manager_v1", 1)
[785451.163] [email protected](33, "zwp_keyboard_shortcuts_inhibit_manager_v1", 1)
[785451.178] [email protected](34, "wl_seat", 7)
[785451.192] -> [email protected](34, "wl_seat", 6, new id [unknown]@11)
[785451.223] [email protected](35, "zwp_pointer_gestures_v1", 1)
[785451.235] [email protected](37, "wl_output", 3)
[785451.251] -> [email protected](37, "wl_output", 3, new id [unknown]@12)
[785451.278] [email protected](45, "wl_output", 3)
[785451.291] -> [email protected](45, "wl_output", 3, new id [unknown]@13)
[785451.308] [email protected](243472)
[785451.316] -> [email protected](new id wl_callback@3)
[785451.358] [email protected]_id(3)
[785451.361] [email protected](0)
[785451.378] [email protected](1)
[785451.383] [email protected](875709016)
[785451.388] [email protected](875708993)
[785451.393] [email protected]("seat0")
[785451.411] [email protected](3)
[785451.419] [email protected](0, 0, 600, 340, 0, "Unknown", "", 1)
[785451.446] [email protected](1, 2560, 1440, 59951)
[785451.454] [email protected](1)
[785451.458] [email protected]()
[785451.475] [email protected](0, 0, 820, 350, 0, "Unknown", "HDMI1", 0)
[785451.494] [email protected](1, 3440, 1440, 99999)
[785451.505] [email protected](1)
[785451.512] [email protected]()
[785451.521] [email protected](243472)
[785451.602] -> [email protected]_surface(new id wl_surface@3)
[785451.618] -> [email protected]_pointer(new id wl_pointer@14)
[785451.652] -> [email protected]_relative_pointer(new id zwp_relative_pointer_v1@15, wl_pointer@14)
[785451.673] -> [email protected]_keyboard(new id wl_keyboard@16)
[785451.783] -> [email protected]_text_input(new id zwp_text_input_v3@17, wl_seat@11)
[785451.925] -> [email protected]_surface(new id wl_surface@18)
[785451.960] -> [email protected](13, "xdg_wm_base", 2, new id [unknown]@19)
[785451.991] -> [email protected]_pool(new id wl_shm_pool@20, fd 14, 128)
[785452.025] -> [email protected]_pool(new id wl_shm_pool@21, fd 16, 128)
[785452.051] -> [email protected]_xdg_surface(new id xdg_surface@22, wl_surface@18)
[785452.069] -> [email protected]_toplevel(new id xdg_toplevel@23)
[785452.080] -> [email protected]()
[785452.089] -> [email protected]_min_size(2, 1)
[785452.098] -> [email protected]_window_geometry(0, 0, 800, 600)
[785452.120] -> [email protected]_surface(new id wl_surface@24)
[785452.131] -> [email protected]_pointer(new id wl_pointer@25)
[785452.158] -> [email protected]_toplevel_decoration(new id zxdg_toplevel_decoration_v1@26, xdg_toplevel@23)
[785452.178] -> [email protected]_mode()
[785452.184] -> [email protected]_min_size(2, 1)
[785452.189] -> [email protected]_max_size(0, 0)
[785452.194] -> [email protected]_min_size(2, 1)
[785452.201] -> [email protected]_max_size(0, 0)
[785452.210] -> [email protected]_title("Muh Window")
[785452.255] -> [email protected](new id wl_callback@27)
[785452.423] [email protected]_id(27)
[785452.432] [email protected](1, fd 14, 47218)
@kchibisov - Ah, including libxkbcommon as a dependency does indeed fix the issue. Thanks for the quick help.
@Slabity yeah, sctk dlopens stuff and I haven't implemented a fallback when libxkbcommon failed to dlopen, thus you have a crash, though, maybe having a better crash for that could help, because I'm not sure if handling wayland keyboard without libxkbcommon is any useful for the user.
The same error occured to me - maybe this issue should be re-opened to add a more helpful error message
I discoverred ths issue whilst trying to run my code on windows via WSL2. I don't usually work on windows, so for me this is not much of an issue, but it might be for others. Is there a way to manually inform the compiler to build for a specific target instead?
I'm having the same issue running WSL2 on windows. Did any of you find a fix? @benediktms @adri326
console:
thread 'main' panicked at 'internal error: entered unreachable code', /home/kristoffer/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.25.0/src/platform_impl/linux/wayland/window/mod.rs:218:77 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace [wayland-client error] A handler for wl_keyboard panicked.
This worked for me: sudo apt install libxkbcommon-dev libegl1 libwayland-dev 🚀
I'm going to reopen this old ticket because I think 2 things need to happen here:
- The
unreachable!()macro needs to be changed to a panic with a detailed error of some sort. It's definitely not an unreachable part of the code, and is causing confusion. - There should be a check that dependencies (or whatever the underlying missing pieces are) are in place. I'm not quite sure how the
libxkbcommon(or other libraries) are normally linked, but normally that happens when the program is loaded into memory, correct? So why isn't the linker complaining about missing libraries?
The unreachable!() macro needs to be changed to a panic with a detailed error of some sort. It's definitely not an unreachable part of the code, and is causing confusion.
The point was, that winit don't plan to support working without libxkbcommon not having it is the only way you can get there, which is not desire. We may have panic telling guesses, but that's all we can, I guess. In general I don't see anything fundamentally wrong with the current approach.
There should be a check that dependencies (or whatever the underlying missing pieces are) are in place. I'm not quite sure how the libxkbcommon (or other libraries) are normally linked, but normally that happens when the program is loaded into memory, correct? So why isn't the linker complaining about missing libraries?
Because it's dlopened, you can disable wayland-dlopen feature to not dlopen it and then it'll complain about the missing libxkbcommon.
The point was, that winit don't plan to support working without libxkbcommon not having it is the only way you can get there, which is not desire. We may have panic telling guesses, but that's all we can, I guess. In general I don't see anything fundamentally wrong with the current approach.
I don't think there's anything fundamentally wrong with throwing a panic as long as the panic itself describes what the error is. But if it's impossible to tell what the error is, then that absolutely sounds like something is fundamentally wrong.
If not having libxkbcommon is the only way to get there as you say it is, then I'm not sure what you mean that a panic would be making a guess though. I might be misunderstanding what this means however.
I think the best solution would be to panic at the dlopen call if it fails, then both developers and package maintainers would be able to tell what their problem is and should have a good idea of how to fix it. That's typically how other programs handle dynamic libraries that are required.
If not having libxkbcommon is the only way to get there as you say it is, then I'm not sure what you mean that a panic would be making a guess though. I might be misunderstanding what this means however.
I'm just saying that it's not forward compatible, but I guess it's fine. The thing is that wayland backend will be rewritten sooner or later(when the wayland-rs api will be more or less stable) and this will be gone naturally...
I think the best solution would be to panic at the dlopen call if it fails, then both developers and package maintainers would be able to tell what their problem is and should have a good idea of how to fix it. That's typically how other programs handle dynamic libraries that are required.
That's inside SCTK, that issue wrt libxkbcommon would be gone entirely in the future.
I'm just saying that it's not forward compatible,
Ah, I see what you're saying now. Sorry, I thought your first two comments were contradicting each other. But yea, if in the future this error could be caused by other sources then saying missing libxkbcommon would likely lead to even more confusion or issues.
~~So are you saying that this crate will eventually move away from SCTK? Or that SCTK will be changing its backend so that this won't be an issue anymore?~~ Nevermind, I somehow glossed over the wayland-rs part.
The wayland-rs 0.30 is a completely different here, also winit will force linking libxkbcommon and won't use sctk at all for example. Though, if we can use some small part of sctk we may use it... The problem is basically that we need more control sometimes than sctk could provide, we already barely use it.