Crash on mouse hover on Wayland

[dandrestor]

Hello,

I am getting a crash running the tutorial code. This is on Fedora 36, running Gnome and Wayland. The window is created normally, but as soon as the mouse cursor hovers the window, the program exits with the following output. If the mouse cursor happens to be within the window bounds when the program starts, the program exits immediately.

Initialized OpenGL with: 4.6 (Core Profile) Mesa 22.1.7, Shader Language Version: 4.60
Error sending request: Resource temporarily unavailable

The contents of the project:

Cargo.toml

[package]
name = "bracket_bug"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
bracket-lib = "0.8"

main.rs

use bracket_lib::prelude::*;

struct State {}

impl GameState for State {
    fn tick(&mut self, ctx: &mut BTerm) {
        ctx.print(1, 1, "Hello Bracket World");
    }
}

fn main() -> BError {
    let context = BTermBuilder::simple80x50()
        .with_title("Hello Minimal Bracket World")
        .build()?;

    let gs: State = State {};
    main_loop(context, gs)
}

I am happy to provide more information, but please bear in mind I am just learning Rust, and I would appreciate it if you could also provide some instructions on how to obtain any traces/logs you might want to see.

[dandrestor]

I just tested and the error does not occur when running with webgpu instead of the default back-end.

[tabvaranjr]

Same issue for me with Fedora 36, GNOME 42 and Wayland. It must be a issue with a project dependency, as it was working correctly until I updated my crates with cargo update a few weeks ago.

If you want to focus on learning Rust with this toolkit and you don't mind using X.org, just switch to a GNOME on X.org session until there's a fix with an upstream dependency.

[JuneKelly]

Same issue on Fedora / Wayland. The webgpu workaround seems to work for me:

# Cargo.toml

[dependencies]
bracket-lib = {version="~0.8", features=["webgpu"], default-features=false }

[BiosElement]

Has there been any other research into this? I gave it a few kicks, tried tracking down the error source and what changed but honestly had little luck.

I did identify that glutin has recently been decoupling from winit to raw-window-handle and moved their 'support' for winit to glutin_winit. Given the crash occurs on mouse-over and not display, it seems the issue would be related to event handling.

[thebracket]

I've been banging my head against this one; Wayland has always been a difficult one, the winit support has wildly varying quality. At one point, I had a "fix" in place because the code for obtaining physical mouse coordinates returned scaled (DPI scaling) numbers, not the real ones - and the code to get the current DPI didn't give the right answer in all cases (Ubunutu would let you set it to 150%, winit returned 1 or 2). It's quite possible that they've finally fixed this, and my "fix" is now breaking it? I'm trying to get a Wayland-based setup going in a VM to hack on - pretty much everything I have is X based, and I use X remote displays a *lot*, so I'm not eager to switch!

…

On Mon, Jan 9, 2023 at 8:37 PM William Chambers ***@***.***> wrote: Has there been any other research into this? I gave it a few kicks, tried tracking down the error source and what changed but honestly had little luck. I did identify that glutin has recently been decoupling from winit to raw-window-handle and moved their 'support' for winit to glutin_winit. Given the crash occurs on mouse-over and not display, it seems the issue would be related to event handling. — Reply to this email directly, view it on GitHub <#318 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADRU435QEABM7QMM42AXX7LWRTDNNANCNFSM6AAAAAAR7BG3EU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[thebracket]

Ok, I can now reproduce it and have a workaround (at least on ubuntu/wayland/gnome in a VM). Enabling the low_cpu feature stops things from crashing.

For example:

cargo run --example astar_mouse --features low_cpu

Works well. Without the feature, it instantly crashes.

So that narrows it down a bit. The issue is that the busy loop is polling Wayland too often, which kills it in response.

[thebracket]

I've added a delay back into the main loop when low_cpu isn't enabled. It's not ideal, but it seems to have solved the crash on my system at least. Anyone care to test it for me, please?

[dandrestor]

Thanks for the update! Confirm not happening anymore on Fedora 37 + Wayland.

[tabvaranjr]

Works correctly with Fedora 37, Wayland and GNOME 43.2. Thanks! 👍

[BiosElement]

I've added a delay back into the main loop when low_cpu isn't enabled. It's not ideal, but it seems to have solved the crash on my system at least. Anyone care to test it for me, please?

I can also confirm it is now running without issue. Glad I mentioned it as I'd have spent ages barking up the wrong tree! Thank ya kindly. 👍

[wildcommunist]

Same issue on Fedora / Wayland. The webgpu workaround seems to work for me:

# Cargo.toml

[dependencies]
bracket-lib = {version="~0.8", features=["webgpu"], default-features=false }

Thank you ser, you are a lifesaver. This issue was driving me insane!

[koslowdavida]

Getting the same bug; waiting on a master build right?

[jantzeno]

I'm working through Hands-on Rust and have the beginning dungeon crawler window with moveable character (page 88).
For posterity, the latest repo commit is 0d2d5e6.

No crash on mouse over using the repo as the dependency:
bracket-lib = { git = "https://github.com/amethyst/bracket-lib.git" }

Operating System: Fedora Linux 38
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.105.0
Graphics Platform: Wayland

[benediktms]

I've added a delay back into the main loop when low_cpu isn't enabled. It's not ideal, but it seems to have solved the crash on my system at least. Anyone care to test it for me, please?

Using this in my project and this fixed the crash for me as well! I'm using Arch with Hyprland as a Compositor

[mvsrgc]

This bug is fixed by upgrading rltk from 0.8.0 to 0.8.7 in Cargo.toml or using rltk = { git = "https://github.com/amethyst/bracket-lib.git" } in Cargo.toml.