Lib crashes on Gnome Wayland when cursor goes over window

[judu]

Libs

• rust_minifb "master".
• wayland 1.18.0 (with libwayland-cursor.so.0.0.0, if relevant)
• Gnome-shell 3.36.2 on gtk+ 3.24.14
• Rust 1.45.2.

The problem

Tried to run the noise example. It runs, it displays noise. But when I move my mouse cursor over the window, the app crashes with the following stack:

Failed to create server-side surface decoration: Missing (<-- This seems to be a warning, displayed when starting the app.)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ()', src/os/posix/wayland.rs:806:21
stack backtrace:
   0:     0x55e96e3e0ef5 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h94b83da514bc2521
   1:     0x55e96e408f2c - core::fmt::write::hf94993d9111a00a2
   2:     0x55e96e3de8d3 - std::io::Write::write_fmt::h5c51319035d46eff
   3:     0x55e96e3e3500 - std::panicking::default_hook::{{closure}}::h47525e4c17161764
   4:     0x55e96e3e324c - std::panicking::default_hook::h851960fd5d052e94
   5:     0x55e96e3e3b37 - std::panicking::rust_panic_with_hook::hd4f116b0d57c3c05
   6:     0x55e96e3e373b - rust_begin_unwind
   7:     0x55e96e408331 - core::panicking::panic_fmt::h01188b0147b5250c
   8:     0x55e96e408153 - core::result::unwrap_failed::h98ead27debe92d1e
   9:     0x55e96e38c636 - core::result::Result<T,E>::unwrap::h4b0caca71f0b009d
                               at /rustc/1.45.2/src/libcore/result.rs:1005
  10:     0x55e96e262bf3 - minifb::os::posix::wayland::Window::update::hb90aa1222bff79c3
                               at src/os/posix/wayland.rs:806
  11:     0x55e96e264725 - minifb::os::posix::wayland::Window::update_with_buffer_stride::h1fee3b234e805836
                               at src/os/posix/wayland.rs:1106
  12:     0x55e96e233cf7 - minifb::os::posix::Window::update_with_buffer_stride::hdff2cc2d6e0a1b22
                               at src/os/posix/mod.rs:82
  13:     0x55e96e22e2bf - minifb::Window::update_with_buffer::hde6d66e0667a607a
                               at /home/judu/tmp/rust_minifb/src/lib.rs:295
  14:     0x55e96e22d9bc - noise::main::h748d4cfb146d3046
                               at examples/noise.rs:69
  15:     0x55e96e22e18b - std::rt::lang_start::{{closure}}::h43464036bb658de3
                               at ../../../../../etc/env.d/alternatives/rust/_current/usr/x86_64-pc-linux-gnu/lib/rustlib/src/rust/src/libstd/rt.rs:67
  16:     0x55e96e3e3f08 - std::rt::lang_start_internal::hee56aadb3f5327f0
  17:     0x55e96e22e167 - std::rt::lang_start::hccb133f873089cc9
                               at ../../../../../etc/env.d/alternatives/rust/_current/usr/x86_64-pc-linux-gnu/lib/rustlib/src/rust/src/libstd/rt.rs:67
  18:     0x55e96e22da6a - main
  19:     0x7fb6b3701033 - __libc_start_main
  20:     0x55e96e22d22e - _start

[emoon]

Thanks for the report!

@nifker any idea about this one?

[emoon]

It seems this code

    fn update_cursor(&mut self, cursor: &str) -> std::result::Result<(), ()> {
        let cursor = self.cursor.get_cursor(cursor);
        if let Some(cursor) = cursor {
            let img = &cursor[0];
            self.cursor_surface.attach(Some(&*img), 0, 0);
            self.cursor_surface.damage(0, 0, 32, 32);
            self.cursor_surface.commit();
            return Ok(());
        }
        Err(())
    }

Will return Err(()) and then we will just unwrap() later on

[nyovaya]

So it looks like the cursor is not provided by the given system: https://smithay.github.io/wayland-rs/wayland_cursor/struct.CursorTheme.html Maybe some cursor theme is being used which doesnt contain all cursors minifb uses.

[judu]

That's fun! I did not know that each wayland client was responsible for displaying the cursor! (Or is it not? That's how I understand it. 🤔) Btw, I'm running the default Gnome theme: Adwaita.

[nyovaya]

Yes but only if you want to display the non-default cursor. Otherwise the libwayland-cursor is not even required. You might want to run it with the flag WAYLAND_DEBUG=1 and post a log(not sure if it gives us more information).

[judu]

The log is here: https://dpaste.com/AP4ZM585G

I'm not sure it will be useful indeed.

[emoon]

Well the weird thing is that noise example doesn't change the cursor so I wonder why this code get trigged then?

[nyovaya]

Because I wrote the code lazily, so that it even loads the default cursor from the CursorTheme.

[emoon]

Right, so the what would be the best way to solve this? I would like to start getting rid of most (all if possible) unwraps that exists in the code (that is for all backends) and trickle back the up to the user. In this case they wouldn't be able to solve it tho as this is an internal thing within minifb

[nyovaya]

As update() returns "()", our option would be to just ok() it.

[emoon]

I think it would be better to return Ok(()) for now, but propagate the errors with a unified Error type for minifb later on. I think handing this one gracefully is better than panic

[nyovaya]

I meant that we cant return Ok there because the function only returns an empty tuple.

[dc740]

Hi, I'm doing a stream about Rust, and got affected by this. minifb is by far mi favorite rust lib, so I'm not complaining, actually, keep it up. I really like being able to have per-pixel access, and also be able to run it on old hardware without drivers, or ancient opengl versions. Going back on topic, I created this PR: https://github.com/emoon/rust_minifb/pull/238

comments, corrections, fixes are all welcome. Feel free to also downvote whatever you don't like. Thanks!

[dc740]

This is working OK. I'm using it on wayland without issues. There is no cursor, obviously, but it no longer closes itself.