Macroquad segfaults in wl_egl_window_resize

[TheZoq2]

Running macroquad in niri fails with a segfault. gdb shows it failing inside wl_egl_window_resize

To reproduce:

Clone https://github.com/not-fl3/macroquad and modify examples/events.rs (or any other event) to

use macroquad::prelude::*;
use miniquad::conf::Platform;

fn main() {
    let config = Conf {
        platform: Platform {
            linux_backend: macroquad::miniquad::conf::LinuxBackend::WaylandOnly,
            ..Default::default()
        },
        ..Default::default()
    };
    macroquad::Window::from_config(config, drawing_loop());
}

async fn drawing_loop() {
    loop {
        next_frame().await;
    }
}

this is needed because macroquad by default runs using x11

Running this example fails with a segfault with the following backtrace

#0  0x00007ffff7f9c108 in wl_egl_window_resize () from /usr/lib/libwayland-egl.so
#1  0x0000555555630775 in miniquad::native::linux_wayland::xdg_toplevel_handle_configure (data=0x7ffffffe7520,
    _toplevel=<optimized out>, width=938, height=1188, _states=<optimized out>) at src/native/linux_wayland.rs:498
#2  0x00007ffff7fa7596 in ?? () from /usr/lib/libffi.so.8
#3  0x00007ffff7fa400e in ?? () from /usr/lib/libffi.so.8
#4  0x00007ffff7fa6bd3 in ffi_call () from /usr/lib/libffi.so.8
#5  0x00007ffff7fb2645 in ?? () from /usr/lib/libwayland-client.so
#6  0x00007ffff7fb2e73 in ?? () from /usr/lib/libwayland-client.so
#7  0x00007ffff7fb313c in wl_display_dispatch_queue_pending () from /usr/lib/libwayland-client.so
#8  0x00007ffff7fb5cf0 in wl_display_roundtrip_queue () from /usr/lib/libwayland-client.so
#9  0x0000555555570caa in miniquad::native::linux_wayland::run<macroquad::{impl#4}::from_config::{closure_env#0}<events::drawing_loop::{async_fn_env#0}>> (conf=0x7ffffffe8878, f=0x7ffffffe873a)
    at /home/frans/.cargo/registry/src/index.crates.io-6f17d22bba15001f/miniquad-0.4.0/src/native/linux_wayland.rs:691
#10 0x0000555555593896 in miniquad::start<macroquad::{impl#4}::from_config::{closure_env#0}<events::drawing_loop::{async_fn_env#0}>> (conf=..., f=...)
    at /home/frans/.cargo/registry/src/index.crates.io-6f17d22bba15001f/miniquad-0.4.0/src/lib.rs:256
#11 0x00005555555755e2 in macroquad::Window::from_config<events::drawing_loop::{async_fn_env#0}> (config=...,
    future=...) at src/lib.rs:765
#12 0x000055555557fae1 in events::main () at examples/events.rs:13

System Information

• niri version: niri 0.1.5 (v0.1.5-57-gd714a71) (the version in Add is_active_in_column #307)

• Distro: Arch

• GPU: TigerLake-LP GT2 [Iris Xe Graphics]

• CPU: Intel i7-1165G7

[kchibisov]

Probably it just passes 0 as window size or something. macroquad bug anyway.

Also, opening issue against from a dev branch is generally not a great idea.

[TheZoq2]

Running it through gdb it appears that egl_window is null

>>> p egl_window

$1 = (struct wl_egl_window *) 0x0

Using the wezterm fix of setting default-column-width { } seems to resolve the issue. Presumably, niri sends a resize message very early, before macroquad has a chance to create a window (or something?)

Probably it just passes 0 as window size or something. macroquad bug anyway.

Seems like it doesn't, it passes wl_egl_window_resize (dy=0, dx=0, height=1188, width=938, egl_window=0x0)

Also, opening issue against from a dev branch is generally not a great idea.

Fair. Since I re-based that branch on main yesterday and it doesn't contain any changes that would cause this. I can re-try this on main if you want me to

[TheZoq2]

Hmm, that null egl_window might not be a problem after all, I can't quite find what that function is used for, but I see several examples which call it with egl_window=0x0

[YaLTeR]

Presumably, niri sends a resize message very early, before macroquad has a chance to create a window (or something?)

niri sends the size in the initial configure (which is part of the Wayland toplevel window creation process). Since that's uncommon among compositors, some clients (like Wezterm) don't handle this case correctly. But it is entirely legal and expected to do so.

[TheZoq2]

Makes sense, I suppose I should go report this on macroquad?

[YaLTeR]

I guess so

[YaLTeR]

Closing because I believe this is not a niri issue. Feel free to reopen if it turns out to be.