-
Notifications
You must be signed in to change notification settings - Fork 880
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"internal error: entered unreachable code" when using Wayland backend #1760
Comments
Some object that was created wasn't assigned to a queue. Could you share a code and |
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:
Here is what I have with WAYLAND_DEBUG=1:
|
@kchibisov - Ah, including |
@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. |
`shell.nix`: Add `libxkbcommon` to `LD_LIBRARY_PATH` `libxkbcommon` is a runtime dependency of winit's Wayland backend. Servo crashes with [a very confusing panic message][1] if the Wayland backend is selected, and `libxkbcommon.so` can't be found at runtime. [1]: rust-windowing/winit#1760 --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [ ] These changes fix #___ (GitHub issue number if applicable) --- - [ ] There are tests for these changes OR - [x] These changes do not require tests because they don't affect the production code
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: |
This worked for me: |
I'm going to reopen this old ticket because I think 2 things need to happen here:
|
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.
Because it's |
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 |
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...
That's inside SCTK, that issue wrt libxkbcommon would be gone entirely in the future. |
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
|
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. |
This update rewrites the winit's Wayland backend using new wayland-rs 0.30 API. This fixes long standing issue with the forward compatibility of the wayland backend, meaning that future updates to the wayland protocol won't break rust code anymore. like it was before when adding new shm/enum variants into the protocol. Fixes rust-windowing#2560. Fixes rust-windowing#2164. Fixes rust-windowing#2128. Fixes rust-windowing#1760. Fixes rust-windowing#725.
This update rewrites the winit's Wayland backend using new wayland-rs 0.30 API. This fixes long standing issue with the forward compatibility of the wayland backend, meaning that future updates to the wayland protocol won't break rust code anymore. like it was before when adding new shm/enum variants into the protocol. Fixes rust-windowing#2560. Fixes rust-windowing#2164. Fixes rust-windowing#2128. Fixes rust-windowing#1760. Fixes rust-windowing#725.
This update rewrites the winit's Wayland backend using new wayland-rs 0.30 API. This fixes long standing issue with the forward compatibility of the wayland backend, meaning that future updates to the wayland protocol won't break rust code anymore. like it was before when adding new shm/enum variants into the protocol. Fixes rust-windowing#2560. Fixes rust-windowing#2164. Fixes rust-windowing#2128. Fixes rust-windowing#1760. Fixes rust-windowing#725.
This update rewrites the winit's Wayland backend using new wayland-rs 0.30 API. This fixes long standing issue with the forward compatibility of the wayland backend, meaning that future updates to the wayland protocol won't break rust code anymore. like it was before when adding new shm/enum variants into the protocol. Fixes rust-windowing#2560. Fixes rust-windowing#2164. Fixes rust-windowing#2128. Fixes rust-windowing#1760. Fixes rust-windowing#725.
This update rewrites the winit's Wayland backend using new wayland-rs 0.30 API. This fixes long standing issue with the forward compatibility of the wayland backend, meaning that future updates to the wayland protocol won't break rust code anymore. like it was before when adding new shm/enum variants into the protocol. Fixes rust-windowing#2560. Fixes rust-windowing#2164. Fixes rust-windowing#2128. Fixes rust-windowing#1760. Fixes rust-windowing#725.
This update rewrites the winit's Wayland backend using new wayland-rs 0.30 API. This fixes long standing issue with the forward compatibility of the wayland backend, meaning that future updates to the wayland protocol won't break rust code anymore. like it was before when adding new shm/enum variants into the protocol. Fixes rust-windowing#2560. Fixes rust-windowing#2164. Fixes rust-windowing#2128. Fixes rust-windowing#1760. Fixes rust-windowing#725.
This update rewrites the winit's Wayland backend using new wayland-rs 0.30 API. This fixes long standing issue with the forward compatibility of the wayland backend, meaning that future updates to the wayland protocol won't break rust code anymore. like it was before when adding new shm/enum variants into the protocol. Fixes rust-windowing#2560. Fixes rust-windowing#2164. Fixes rust-windowing#2128. Fixes rust-windowing#1760. Fixes rust-windowing#725.
This update rewrites the winit's Wayland backend using new wayland-rs 0.30 API. This fixes long standing issue with the forward compatibility of the wayland backend, meaning that future updates to the wayland protocol won't break rust code anymore. like it was before when adding new shm/enum variants into the protocol. Fixes #2560. Fixes #2164. Fixes #2128. Fixes #1760. Fixes #725.
To run example/gui/hello.roc in Wayland (NixOS) Error message: rust-windowing/winit#1760 I ran it as usual with `nix-shell`, and then executed it using `nixVulkanIntel ../roc ../hello.rc`. After adding two dependencies, it runs well. Signed-off-by: GuruPoo <plumpmath@gmail.com>
Attempting to create a Window on the Wayland backend on my system results in the following:
Which seems to be coming from this:
Can anyone explain what this little piece of code is doing and what would cause the it to be reachable?
The text was updated successfully, but these errors were encountered: