glfw: Illegal instruction in `pollEvents()` #75

New issue

Closed

opened 2021-11-15 11:42:42 +00:00 by alichraghi · 5 comments

alichraghi commented

2021-11-15 11:42:42 +00:00

(Migrated from github.com)

Code

const std = @import("std");
const glfw = @import("glfw");
const mem = std.mem;

fn printKey(window: glfw.Window, key: glfw.Key, scancode: isize, action: glfw.Action, mods: glfw.Mods) void  {
    _ = window;
    _ = scancode;
    _ = action;
    _ = mods;
    std.debug.print("{s}\n", .{key});
}

pub fn main() !void {
    try glfw.init();
    defer glfw.terminate();

    try glfw.Window.hint(glfw.Window.Hint.context_version_major, 4);
    try glfw.Window.hint(glfw.Window.Hint.context_version_minor, 5);
    const window = try glfw.Window.create(640, 480, "Hello, mach-glfw!", null, null);
    defer window.destroy();
    try glfw.makeContextCurrent(window);
    window.setKeyCallback(printKey);

    while (!window.shouldClose()) {
        try window.swapBuffers();
        try glfw.pollEvents();
    }
}

while the above code running, if you press a keyboard key that will crash with this messsage:

Illegal instruction at address 0x26832c
lib/glfw/upstream/glfw/src/x11_window.c:0:0: 0x26832c in _glfwPlatformPollEvents (/home/ali/dev/kizi/lib/glfw/upstream/glfw/src/x11_window.c)
lib/glfw/upstream/glfw/src/window.c:1072:5: 0x274e74 in glfwPollEvents (/home/ali/dev/kizi/lib/glfw/upstream/glfw/src/window.c)
    _glfwPlatformPollEvents();
    ^
/home/ali/dev/kizi/lib/glfw/src/main.zig:189:21: 0x22b4fd in main (kizi)
    c.glfwPollEvents();

<details> <summary>Code</summary> ```zig const std = @import("std"); const glfw = @import("glfw"); const mem = std.mem; fn printKey(window: glfw.Window, key: glfw.Key, scancode: isize, action: glfw.Action, mods: glfw.Mods) void { _ = window; _ = scancode; _ = action; _ = mods; std.debug.print("{s}\n", .{key}); } pub fn main() !void { try glfw.init(); defer glfw.terminate(); try glfw.Window.hint(glfw.Window.Hint.context_version_major, 4); try glfw.Window.hint(glfw.Window.Hint.context_version_minor, 5); const window = try glfw.Window.create(640, 480, "Hello, mach-glfw!", null, null); defer window.destroy(); try glfw.makeContextCurrent(window); window.setKeyCallback(printKey); while (!window.shouldClose()) { try window.swapBuffers(); try glfw.pollEvents(); } } ``` </details> while the above code running, if you press a keyboard key that will crash with this messsage: ```rs Illegal instruction at address 0x26832c lib/glfw/upstream/glfw/src/x11_window.c:0:0: 0x26832c in _glfwPlatformPollEvents (/home/ali/dev/kizi/lib/glfw/upstream/glfw/src/x11_window.c) lib/glfw/upstream/glfw/src/window.c:1072:5: 0x274e74 in glfwPollEvents (/home/ali/dev/kizi/lib/glfw/upstream/glfw/src/window.c) _glfwPlatformPollEvents(); ^ /home/ali/dev/kizi/lib/glfw/src/main.zig:189:21: 0x22b4fd in main (kizi) c.glfwPollEvents(); ```

alichraghi commented

2021-11-15 18:38:47 +00:00

(Migrated from github.com)

i think this is because currently mach can't build for wayland

emidoots commented

2021-11-15 23:26:45 +00:00

(Migrated from github.com)

Hi @AliChraghi - thanks for the bug report! A few things:

I believe that @silversquirl's patch in https://github.com/hexops/mach/pull/72 likely fixes this, please try again and let me know. I do not think it is caused by any mismatch of Wayland vs. X11 support but rather is undefined behavior being caught in the GLFW source code by Zig / UBSan.
You can build for Wayland if you like today by changing your build.zig:

-glfw.link(b, exe, .{});
+glfw.link(b, exe, .{.linux_window_manager = .Wayland});

It should "just work", but there may be unknown issues present. I wouldn't advise doing this however as GLFW's Wayland backend is still very immature, in the next version of GLFW there will be support for choosing between X11 and Wayland backends at runtime and so we will begin building for both by default. https://github.com/glfw/glfw/pull/1958

If you continue to run into such illegal instruction crashes, you can workaround them by building with -Drelease-fast temporarily as that will have Zig disable UBSan - until we track down the source of the undefined behavior and patch it in GLFW source code.

Hi @AliChraghi - thanks for the bug report! A few things: 1. I believe that @silversquirl's patch in https://github.com/hexops/mach/pull/72 likely fixes this, please try again and let me know. I do not think it is caused by any mismatch of Wayland vs. X11 support but rather is undefined behavior being caught in the GLFW source code by Zig / UBSan. 2. You can build for Wayland if you like today by changing your `build.zig`: ```diff -glfw.link(b, exe, .{}); +glfw.link(b, exe, .{.linux_window_manager = .Wayland}); ``` It should "just work", but there may be unknown issues present. I wouldn't advise doing this however as GLFW's Wayland backend is still very immature, in the next version of GLFW there will be support for choosing between X11 and Wayland backends at runtime and so we will begin building for both by default. https://github.com/glfw/glfw/pull/1958 3. If you continue to run into such illegal instruction crashes, you can workaround them by building with `-Drelease-fast` temporarily as that will have Zig disable UBSan - until we track down the source of the undefined behavior and patch it in GLFW source code.

👍 1

alichraghi commented

2021-11-15 23:45:40 +00:00

(Migrated from github.com)

thank you! #72 worked for X11. but adding .linux_window_manager = .Wayland cause build error. i believe that's because:

typing mistake in build.zig

- .Wayland => "_D_GLFW_WAYLAND",
+ .Wayland => "-D_GLFW_WAYLAND",

github.com/hexops/mach@82a9cf616d/glfw/build.zig (L126)

there's a missing header file in lib/glfw/upstream/glfw/src called wayland-xdg-shell-client-protocol.h.

thank you! #72 worked for X11. but adding `.linux_window_manager = .Wayland` cause build error. i believe that's because: - typing mistake in `build.zig` ```diff - .Wayland => "_D_GLFW_WAYLAND", + .Wayland => "-D_GLFW_WAYLAND", ``` https://github.com/hexops/mach/blob/82a9cf616d347d7e1b521e73c1e9058b42f5bbd1/glfw/build.zig#L126 - there's a missing header file in `lib/glfw/upstream/glfw/src` called `wayland-xdg-shell-client-protocol.h`.

emidoots commented

2021-11-16 00:31:25 +00:00

(Migrated from github.com)

Ahh, okay. I will see if I can fix this soon (unless someone wants to try and sends PRs for it!)

You're right about the typo.

For wayland-xdg-shell, we will need to add the right apt packages to the fecth.sh script here so our SDK has the headers/libs so we can cross compile. https://github.com/hexops/sdk-linux-x86_64

Ahh, okay. I will see if I can fix this soon (unless someone wants to try and sends PRs for it!) You're right about the typo. For wayland-xdg-shell, we will need to add the right apt packages to the `fecth.sh` script here so our SDK has the headers/libs so we can cross compile. https://github.com/hexops/sdk-linux-x86_64

👍 1

emidoots commented

2021-11-16 00:34:48 +00:00

(Migrated from github.com)

Filed https://github.com/hexops/mach/issues/76 and https://github.com/hexops/mach/issues/77 to track these two issues. I will close this one since the original illegal instruction issue is fixed.