"internal error: entered unreachable code" when using Wayland backend

[Slabity]

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?

[kchibisov]

Some object that was created wasn't assigned to a queue. Could you share a code and WAYLAND_DEBUG=1 output?

[kchibisov]

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.

[Slabity]

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]  -> wl_display@1.get_registry(new id wl_registry@2)
[785450.482]  -> wl_display@1.sync(new id wl_callback@3)
[785450.543] wl_display@1.delete_id(3)
[785450.565] wl_registry@2.global(1, "wl_shm", 1)
[785450.644]  -> wl_registry@2.bind(1, "wl_shm", 1, new id [unknown]@4)
[785450.687] wl_registry@2.global(2, "wl_drm", 2)
[785450.696] wl_registry@2.global(3, "zwp_linux_dmabuf_v1", 3)
[785450.707] wl_registry@2.global(4, "wl_compositor", 4)
[785450.723]  -> wl_registry@2.bind(4, "wl_compositor", 4, new id [unknown]@5)
[785450.744] wl_registry@2.global(5, "wl_subcompositor", 1)
[785450.758]  -> wl_registry@2.bind(5, "wl_subcompositor", 1, new id [unknown]@6)
[785450.774] wl_registry@2.global(6, "wl_data_device_manager", 3)
[785450.783] wl_registry@2.global(7, "zwlr_gamma_control_manager_v1", 1)
[785450.796] wl_registry@2.global(8, "gtk_primary_selection_device_manager", 1)
[785450.805] wl_registry@2.global(9, "zxdg_output_manager_v1", 3)
[785450.820] wl_registry@2.global(10, "org_kde_kwin_idle", 1)
[785450.833] wl_registry@2.global(11, "zwp_idle_inhibit_manager_v1", 1)
[785450.846] wl_registry@2.global(12, "zwlr_layer_shell_v1", 2)
[785450.854] wl_registry@2.global(13, "xdg_wm_base", 2)
[785450.865] wl_registry@2.global(14, "zwp_tablet_manager_v2", 1)
[785450.882] wl_registry@2.global(15, "org_kde_kwin_server_decoration_manager", 1)
[785450.893] wl_registry@2.global(16, "zxdg_decoration_manager_v1", 1)
[785450.913]  -> wl_registry@2.bind(16, "zxdg_decoration_manager_v1", 1, new id [unknown]@7)
[785450.929] wl_registry@2.global(17, "zwp_relative_pointer_manager_v1", 1)
[785450.944]  -> wl_registry@2.bind(17, "zwp_relative_pointer_manager_v1", 1, new id [unknown]@8)
[785450.959] wl_registry@2.global(18, "zwp_pointer_constraints_v1", 1)
[785450.975]  -> wl_registry@2.bind(18, "zwp_pointer_constraints_v1", 1, new id [unknown]@9)
[785450.990] wl_registry@2.global(19, "wp_presentation", 1)
[785451.002] wl_registry@2.global(20, "zwlr_output_manager_v1", 1)
[785451.014] wl_registry@2.global(21, "zwlr_output_power_manager_v1", 1)
[785451.028] wl_registry@2.global(22, "zwp_input_method_manager_v2", 1)
[785451.039] wl_registry@2.global(23, "zwp_text_input_manager_v3", 1)
[785451.055]  -> wl_registry@2.bind(23, "zwp_text_input_manager_v3", 1, new id [unknown]@10)
[785451.071] wl_registry@2.global(24, "zwlr_foreign_toplevel_manager_v1", 2)
[785451.084] wl_registry@2.global(25, "zwlr_export_dmabuf_manager_v1", 1)
[785451.094] wl_registry@2.global(26, "zwlr_screencopy_manager_v1", 3)
[785451.106] wl_registry@2.global(27, "zwlr_data_control_manager_v1", 2)
[785451.114] wl_registry@2.global(28, "zwp_primary_selection_device_manager_v1", 1)
[785451.124] wl_registry@2.global(29, "wp_viewporter", 1)
[785451.132] wl_registry@2.global(30, "zwp_virtual_keyboard_manager_v1", 1)
[785451.142] wl_registry@2.global(31, "zwlr_virtual_pointer_manager_v1", 2)
[785451.151] wl_registry@2.global(32, "zwlr_input_inhibit_manager_v1", 1)
[785451.163] wl_registry@2.global(33, "zwp_keyboard_shortcuts_inhibit_manager_v1", 1)
[785451.178] wl_registry@2.global(34, "wl_seat", 7)
[785451.192]  -> wl_registry@2.bind(34, "wl_seat", 6, new id [unknown]@11)
[785451.223] wl_registry@2.global(35, "zwp_pointer_gestures_v1", 1)
[785451.235] wl_registry@2.global(37, "wl_output", 3)
[785451.251]  -> wl_registry@2.bind(37, "wl_output", 3, new id [unknown]@12)
[785451.278] wl_registry@2.global(45, "wl_output", 3)
[785451.291]  -> wl_registry@2.bind(45, "wl_output", 3, new id [unknown]@13)
[785451.308] wl_callback@3.done(243472)
[785451.316]  -> wl_display@1.sync(new id wl_callback@3)
[785451.358] wl_display@1.delete_id(3)
[785451.361] wl_shm@4.format(0)
[785451.378] wl_shm@4.format(1)
[785451.383] wl_shm@4.format(875709016)
[785451.388] wl_shm@4.format(875708993)
[785451.393] wl_seat@11.name("seat0")
[785451.411] wl_seat@11.capabilities(3)
[785451.419] wl_output@12.geometry(0, 0, 600, 340, 0, "Unknown", "", 1)
[785451.446] wl_output@12.mode(1, 2560, 1440, 59951)
[785451.454] wl_output@12.scale(1)
[785451.458] wl_output@12.done()
[785451.475] wl_output@13.geometry(0, 0, 820, 350, 0, "Unknown", "HDMI1", 0)
[785451.494] wl_output@13.mode(1, 3440, 1440, 99999)
[785451.505] wl_output@13.scale(1)
[785451.512] wl_output@13.done()
[785451.521] wl_callback@3.done(243472)
[785451.602]  -> wl_compositor@5.create_surface(new id wl_surface@3)
[785451.618]  -> wl_seat@11.get_pointer(new id wl_pointer@14)
[785451.652]  -> zwp_relative_pointer_manager_v1@8.get_relative_pointer(new id zwp_relative_pointer_v1@15, wl_pointer@14)
[785451.673]  -> wl_seat@11.get_keyboard(new id wl_keyboard@16)
[785451.783]  -> zwp_text_input_manager_v3@10.get_text_input(new id zwp_text_input_v3@17, wl_seat@11)
[785451.925]  -> wl_compositor@5.create_surface(new id wl_surface@18)
[785451.960]  -> wl_registry@2.bind(13, "xdg_wm_base", 2, new id [unknown]@19)
[785451.991]  -> wl_shm@4.create_pool(new id wl_shm_pool@20, fd 14, 128)
[785452.025]  -> wl_shm@4.create_pool(new id wl_shm_pool@21, fd 16, 128)
[785452.051]  -> xdg_wm_base@19.get_xdg_surface(new id xdg_surface@22, wl_surface@18)
[785452.069]  -> xdg_surface@22.get_toplevel(new id xdg_toplevel@23)
[785452.080]  -> wl_surface@18.commit()
[785452.089]  -> xdg_toplevel@23.set_min_size(2, 1)
[785452.098]  -> xdg_surface@22.set_window_geometry(0, 0, 800, 600)
[785452.120]  -> wl_compositor@5.create_surface(new id wl_surface@24)
[785452.131]  -> wl_seat@11.get_pointer(new id wl_pointer@25)
[785452.158]  -> zxdg_decoration_manager_v1@7.get_toplevel_decoration(new id zxdg_toplevel_decoration_v1@26, xdg_toplevel@23)
[785452.178]  -> zxdg_toplevel_decoration_v1@26.unset_mode()
[785452.184]  -> xdg_toplevel@23.set_min_size(2, 1)
[785452.189]  -> xdg_toplevel@23.set_max_size(0, 0)
[785452.194]  -> xdg_toplevel@23.set_min_size(2, 1)
[785452.201]  -> xdg_toplevel@23.set_max_size(0, 0)
[785452.210]  -> xdg_toplevel@23.set_title("Muh Window")
[785452.255]  -> wl_display@1.sync(new id wl_callback@27)
[785452.423] wl_display@1.delete_id(27)
[785452.432] wl_keyboard@16.keymap(1, fd 14, 47218)

[Slabity]

@kchibisov - Ah, including libxkbcommon as a dependency does indeed fix the issue. Thanks for the quick help.

[kchibisov]

@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.

[adri326]

The same error occured to me - maybe this issue should be re-opened to add a more helpful error message

[benediktms]

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?

[Sollimann]

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.

[Sollimann]

This worked for me: sudo apt install libxkbcommon-dev libegl1 libwayland-dev 🚀

[Slabity]

I'm going to reopen this old ticket because I think 2 things need to happen here:

1. 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.
2. 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?

[kchibisov]

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.

[Slabity]

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.

[kchibisov]

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.

[Slabity]

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.

[kchibisov]

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.