Core: triangle example crashes at runtime on wayland with segmentation fault.

[nippi05]

> ~/zig/0.13.0-dev.351+64ef45eb0/files/zig build run-triangle
Segmentation fault at address 0x40
???:?:?: 0x7f2b2d690700 in ??? (libwayland-client.so.0)
Unwind information for `libwayland-client.so.0:0x7f2b2d690700` was not available, trace may be incomplete

/home/nilsj/Projects/zfps/libs/mach/src/core/linux/Wayland.zig:158:76: 0x10c7e2a in init (core-triangle)
    const decoration = c.zxdg_decoration_manager_v1_get_toplevel_decoration(
                                                                           ^
/home/nilsj/Projects/zfps/libs/mach/src/core/Linux.zig:94:41: 0x10c9272 in init (core-triangle)
            const wayland = Wayland.init(linux, core, options) catch |err| switch (err) {
                                        ^
/home/nilsj/Projects/zfps/libs/mach/src/Core.zig:210:22: 0x10dd47e in init (core-triangle)
    try Platform.init(&state.platform, core, options);
                     ^
/home/nilsj/Projects/zfps/libs/mach/src/module/module.zig:444:32: 0x113ae10 in dispatchInternal__anon_13063 (core-triangle)
                .ErrorUnion => try @call(.auto, handler, args),
                               ^
/home/nilsj/Projects/zfps/libs/mach/src/module/module.zig:360:38: 0x113c74f in dispatch (core-triangle)
            return m.dispatchInternal(stack_space, options, injectable);
                                     ^
/home/nilsj/Projects/zfps/libs/mach/examples/core/triangle/main.zig:23:27: 0x113c89e in main (core-triangle)
    try mach.mods.dispatch(stack_space, .{});
                          ^
/home/nilsj/zig/0.13.0-dev.351+64ef45eb0/files/lib/std/start.zig:524:37: 0x113ccde in main (core-triangle)
            const result = root.main() catch |err| {
                                    ^
run-triangle
└─ run core-triangle failure
error: the following command terminated unexpectedly:
/home/nilsj/Projects/zfps/libs/mach/zig-out/bin/core-triangle
Build Summary: 53/55 steps succeeded; 1 failed (disable with --summary none)
run-triangle transitive failure
└─ run core-triangle failure
error: the following build command failed with exit code 1:
/home/nilsj/Projects/zfps/libs/mach/.zig-cache/o/7cfc9a16a152f450c50d3b7c363cfb8b/build /home/nilsj/zig/0.13.0-dev.351+64ef45eb0/files/zig /home/nilsj/Projects/zfps/libs/mach /home/nilsj/Projects/zfps/libs/mach/.zig-cache /home/nilsj/.cache/zig --seed 0x7c877ff2 -Z24801e53fa41fc62 run-triangle

[RonaldZielaznicki]

@nippi05 Would you be able to confirm that https://github.com/hexops/mach/pull/1289 fixes this issue?

[nippi05]

@RonaldZielaznicki I'm still getting the same error 😕

[RonaldZielaznicki]

@nippi05

Hrrrm. And just to cover the bases, this is while running the latest main? Or are you running 4.0?

[nippi05]

@RonaldZielaznicki yes master.

[dysphoriac]

which compositor are you using? also try running it with WAYLAND_DEBUG=1 as an environment variable another thing is you're running 0.13.0-dev.351+64ef45eb0, try the mach nominated zig version

[nippi05]

It's gnome so Mutter(?). I'm using mach nominated version here is output with WAYLAND_DEBUG=1:

~/Projects/zfps/libs/mach main 29s ❯ zig version           
0.14.0-dev.1911+3bf89f55c
~/Projects/zfps/libs/mach main ❯ WAYLAND_DEBUG=1 zig build run-triangle
[1642744.646]  -> wl_display@1.get_registry(new id wl_registry@2)
[1642744.660]  -> wl_display@1.sync(new id wl_callback@3)
[1642744.807] wl_display@1.delete_id(3)
[1642744.819] wl_registry@2.global(1, "wl_compositor", 5)
[1642744.831]  -> wl_registry@2.bind(1, "wl_compositor", 3, new id [unknown]@4)
[1642744.840] wl_registry@2.global(2, "wl_drm", 2)
[1642744.847] wl_registry@2.global(3, "wl_shm", 1)
[1642744.856]  -> wl_registry@2.bind(3, "wl_shm", 1, new id [unknown]@5)
[1642744.864] wl_registry@2.global(4, "wl_output", 3)
[1642744.872]  -> wl_registry@2.bind(4, "wl_output", 3, new id [unknown]@6)
[1642744.880] wl_registry@2.global(5, "zxdg_output_manager_v1", 3)
[1642744.886] wl_registry@2.global(6, "wl_data_device_manager", 3)
[1642744.893] wl_registry@2.global(7, "zwp_primary_selection_device_manager_v1", 1)
[1642744.902] wl_registry@2.global(8, "wl_subcompositor", 1)
[1642744.910]  -> wl_registry@2.bind(8, "wl_subcompositor", 1, new id [unknown]@7)
[1642744.915] wl_registry@2.global(9, "xdg_wm_base", 4)
[1642744.926]  -> wl_registry@2.bind(9, "xdg_wm_base", 3, new id [unknown]@8)
[1642744.932] wl_registry@2.global(10, "gtk_shell1", 5)
[1642744.938] wl_registry@2.global(11, "wp_viewporter", 1)
[1642744.945] wl_registry@2.global(12, "zwp_pointer_gestures_v1", 3)
[1642744.951] wl_registry@2.global(13, "zwp_tablet_manager_v2", 1)
[1642744.956] wl_registry@2.global(14, "wl_seat", 8)
[1642744.963]  -> wl_registry@2.bind(14, "wl_seat", 3, new id [unknown]@9)
[1642744.969] wl_registry@2.global(15, "zwp_relative_pointer_manager_v1", 1)
[1642744.976] wl_registry@2.global(16, "zwp_pointer_constraints_v1", 1)
[1642744.982] wl_registry@2.global(17, "zxdg_exporter_v1", 1)
[1642744.988] wl_registry@2.global(18, "zxdg_importer_v1", 1)
[1642744.994] wl_registry@2.global(19, "zwp_linux_dmabuf_v1", 4)
[1642745.000] wl_registry@2.global(20, "wp_single_pixel_buffer_manager_v1", 1)
[1642745.006] wl_registry@2.global(21, "zwp_keyboard_shortcuts_inhibit_manager_v1", 1)
[1642745.013] wl_registry@2.global(22, "zwp_text_input_manager_v3", 1)
[1642745.019] wl_registry@2.global(23, "wp_presentation", 1)
[1642745.025] wl_registry@2.global(24, "xdg_activation_v1", 1)
[1642745.031] wl_callback@3.done(3082)
[1642745.038]  -> wl_display@1.sync(new id wl_callback@3)
[1642745.139] wl_display@1.delete_id(3)
[1642745.151] wl_seat@9.capabilities(3)
[1642745.158]  -> wl_seat@9.get_keyboard(new id wl_keyboard@10)
[1642745.166]  -> wl_seat@9.get_pointer(new id wl_pointer@11)
[1642745.172] wl_seat@9.name("seat0")
[1642745.178] wl_callback@3.done(3082)
[1642745.184]  -> wl_compositor@4.create_surface(new id wl_surface@3)
[1642745.191]  -> wl_compositor@4.create_region(new id wl_region@12)
[1642745.198]  -> wl_region@12.add(0, 0, 960, 540)
[1642745.204]  -> wl_surface@3.set_opaque_region(wl_region@12)
[1642745.210]  -> wl_region@12.destroy()
[1642745.217]  -> xdg_wm_base@8.get_xdg_surface(new id xdg_surface@13, wl_surface@3)
[1642745.228]  -> xdg_surface@13.get_toplevel(new id xdg_toplevel@14)
[1642745.234]  -> wl_surface@3.commit()
[1642747.342] wl_display@1.delete_id(12)
[1642747.359] wl_keyboard@10.keymap(1, fd 4, 76270)
[1642754.533] xdg_toplevel@14.configure(0, 0, array[0])
[1642754.548] xdg_surface@13.configure(115)
[1642754.556]  -> xdg_surface@13.ack_configure(115)
[1642754.564]  -> wl_compositor@4.create_region(new id wl_region@12)
[1642754.570]  -> wl_region@12.add(0, 0, 960, 540)
[1642754.577]  -> wl_surface@3.set_opaque_region(wl_region@12)
[1642754.582]  -> wl_region@12.destroy()
[1642754.589]  -> xdg_toplevel@14.set_title("Mach core")
Segmentation fault at address 0x40
???:?:?: 0x7ff519746700 in ??? (libwayland-client.so.0)
Unwind information for `libwayland-client.so.0:0x7ff519746700` was not available, trace may be incomplete

/home/nilsj/Projects/zfps/libs/mach/src/core/linux/Wayland.zig:158:76: 0x10f2273 in init (core-triangle)
    const decoration = c.zxdg_decoration_manager_v1_get_toplevel_decoration(
                                                                           ^
/home/nilsj/Projects/zfps/libs/mach/src/core/Linux.zig:104:41: 0x10f3f58 in init (core-triangle)
            const wayland = Wayland.init(linux, core, options) catch |err| {
                                        ^
/home/nilsj/Projects/zfps/libs/mach/src/Core.zig:210:22: 0x110833e in init (core-triangle)
    try Platform.init(&state.platform, core, options);
                     ^
/home/nilsj/Projects/zfps/libs/mach/src/module/module.zig:444:33: 0x116a112 in dispatchInternal__anon_10183 (core-triangle)
                .error_union => try @call(.auto, handler, args),
                                ^
/home/nilsj/Projects/zfps/libs/mach/src/module/module.zig:360:38: 0x116b89f in dispatch (core-triangle)
            return m.dispatchInternal(stack_space, options, injectable);
                                     ^
/home/nilsj/Projects/zfps/libs/mach/examples/core/triangle/main.zig:23:27: 0x116b9ee in main (core-triangle)
    try mach.mods.dispatch(stack_space, .{});
                          ^
/home/nilsj/zig/0.14.0-dev.1911+3bf89f55c/files/lib/std/start.zig:621:37: 0x116be2e in main (core-triangle)
            const result = root.main() catch |err| {
                                    ^
run-triangle
└─ run core-triangle failure
error: the following command terminated unexpectedly:
/home/nilsj/Projects/zfps/libs/mach/zig-out/bin/core-triangle 
Build Summary: 44/46 steps succeeded; 1 failed
run-triangle transitive failure
└─ run core-triangle failure
error: the following build command failed with exit code 1:
/home/nilsj/Projects/zfps/libs/mach/.zig-cache/o/aace89b9cb039f7ed7d7b50486356fc2/build /home/nilsj/zig/0.14.0-dev.1911+3bf89f55c/files/zig /home/nilsj/zig/0.14.0-dev.1911+3bf89f55c/files/lib /home/nilsj/Projects/zfps/libs/mach /home/nilsj/Projects/zfps/libs/mach/.zig-cache /home/nilsj/.cache/zig --seed 0x984f4825 -Zcccc9b2d2b473923 run-triangle

[dysphoriac]

it looks like its trying to set the decoration mode using the xdg-decoration protocol but that protocol is not implemented by mutter, so its just trying to access a out of bounds memory address, and it segfaults.

unfortunately unless gnome implements the protocol and provides server side decoration, which is unlikely , mach might have to provide some sort of client side decoration in order to work on fully gnome

these are basically the options:

1. add csd to mach.

undesirable for mach devs, would probably mean adding libdecor or something like that

2. add ssd to mutter

undesirable for gnome devs, unlikely due to philosophical differences

3. just add something that disables the checks if the zxdg_decoration_manager_v1 exists before calling c.zxdg_decoration_manager_v1_get_toplevel_decoration()

would break window moving and resizing, kinda hacky, undesirable for everyone

[RonaldZielaznicki]

Thank you for the insight dysphoriac. And ain't that just frustrating, looks like we're betweeen a rock and a hard place here. Checked in on the docs for the protocol, and they've a helpful graphic.

@slimsag Mind if I ask your opinion on what direction we'd like to go?

[slimsag]

I believe that GLFW also uses libdecor by default, falling back to SSD only if libdecor is not found.

I think we should do the same here. And, obviously, we should std.DynLib the dependency on libdecor and not rely on system headers for compilation so that cross compilation works.

If libdecor is not available, we should fallback to SSD. If SSD is not available, then let's exit with an error message telling the user their OS is broken and to install libdecor - rather than e.g. having an unresizable window

[RonaldZielaznicki]

Think as a stopgap, I'll throw up a PR that'll give a proper error if SSD is not supported.

That way we'll stop getting new/similar reports about if while libdecor is hooked up.

[slimsag]

That sounds perfect