Panic when printing after Raylib's InitWindow()

[njnj]

Hello fellow Zig fans!

First of all, thanks for this amazing language! It’s easy to use and it compiles fast (unlike some other languages).

So, I’ve been experimenting with Zig and Raylib for some time and came across what I can only assume to be a bug.

Here’s a minimal reproducer.

const rl = @cImport(@cInclude("raylib.h"));
const print = @import("std").debug.print;

pub fn main() void {
  print("Before InitWindow()\n", .{});
  rl.InitWindow(300, 200, "Test");
  print("After InitWindow()\n", .{});
  rl.CloseWindow();
}

Write to main.zig and run:

zig run --library "c" --library "raylib" main.zig

It should work just fine.

Now, comment out the first print() statement and re-run.
There is the usual Raylib output, but then, the program panics with the following message.

thread 16078 panic: attempt to use null value

Note that it also happens with the following as print functions:

• std.log.info
• std.log.debug

Environment:

• Zig version: 0.16.0 (via Nixpkgs)
• Raylib version: 6.0 (via Nixpkgs)
• Target: x86_64-linux
• Graphical: Sway (Wayland)

Unless I print at least once before InitWindow(), any call to print() will trigger a panic.
Unfortunately, I don’t know how to take my investigation further, hence this post.

That being said, I suspect it might be related to the following…

Thread panic when returning an error after initializing GLFW

Hi, I ran into an issue using GLFW with Zig 0.16.0 on Gentoo (Wayland/niri). I first hit this in a bigger project, where I could open a window and render OpenGL quads fine, so GLFW itself is working. The panic only shows up when an error propagates out of main unhandled. Here’s the smallest repro I could get it down to: main.zig const std = @import("std"); const c = @cImport({ @cInclude("GLFW/glfw3.h"); }); pub fn main(init: std.process.Init) !void { _ = init; if (c.glfwInit() ==…

Your input would be appreciated. Thank you!

[castholm]

@njnj

Unless I print at least once before InitWindow(), any call to print() will trigger a panic.
Unfortunately, I don’t know how to take my investigation further, hence this post.

The fact that the early print statement prevents a crash strongly suggests that you’re hitting the same bug as the one from the thread you linked.

Thread panic when returning an error after initializing GLFW

Based on entry 16 my suspicion is that GLFW is modifying environ/envp. Zig std incorrectly assumes that envp is immutable and eagerly computes the length and converts it into a slice on startup, and Io.Threaded.Environ.scan will iterate over the full slice by length and not by scanning for the null sentinel, so if GLFW has used libc to modify the environment you end up with this crash. The hang is because stderr is already locked by the time the panic handler tries to lock it for writing. This…

https://codeberg.org/ziglang/zig/issues/35512

To work around the bug without actually printing anything to the console, you can add these two statements to the very top of your main function:

 const rl = @cImport(@cInclude("raylib.h"));
 const print = @import("std").debug.print;
 
 pub fn main() void {
-    print("Before InitWindow()\n", .{});
+    std.debug.lockStderr(&.{});
+    std.debug.unlockStderr();
     rl.InitWindow(300, 200, "Test");
     print("After InitWindow()\n", .{});
     rl.CloseWindow();
 }