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 is a known bug: https://codeberg.org/ziglang/zig/issues/35512
You might be able to work around it by adding
pub fn main(init: std.process.Init) !void {
std.debug.lockStderr(&.{});
std.debug.unlockStderr();
}
as your first two lines of your main function, before you initialize GLFW. This should trigger a scan for terminal color preference-related environment variables (e.g. NO_COLOR) and the result will subsequently be cached for the remainder of the application’s runtime, so that it won’t be affected if libc is used to mutate environ.
Whether or not envp (the C main argument) and environ alias or affect each other is an implementation detail of the libc, so that might explain why some OSes/distros have the problem and others don’t. (And Windows also handles environment variables very differently from POSIX.)