Panic when printing after Raylib's InitWindow()

[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();
 }