Zig Version
0.16.0-dev.2223+4f16e80ce
Steps to Reproduce and Observed Behavior
When I try to run std.log.info after glfwinit...
conststd=@import("std");constc=@cImport(@cInclude("GLFW/glfw3.h"));pubfnmain()void{// std.debug.print("", .{}); // Somehow this fixes it?_=c.glfwInit();std.log.info("Hello",.{});// PANIC}zig build-exe repro.zig -lc -lglfw && ./repro
panics with:
thread 114247 panic: attempt to use null value
aborting due to recursive panic
fish: Job 2, './repro' terminated by signal SIGABRT (Abort)
From what i saw it panics at
https://codeberg.org/ziglang/zig/src/branch/master/lib/std/Io/Threaded.zig#L13214
I have no experience in zig's codebase. My guess is it has something to do with environment
LD_DEBUG=bindings ./repro 2>&1 | grep setenv
there are a few setenvs which might cause relocation as many c libraries do like glfw ... and from I could tell, the environment pointer is stored at the start might go stale when scanEnviron tries to read it. That's why I assume std.debug.print before it fixes it. because then scanEnviron exits early once initlialized...
Not sure though : ) just eyeballed it.
Expected Behavior
There is should be no panic, it didn't happen before in zig so I assume this a regression.
### Zig Version
0.16.0-dev.2223+4f16e80ce
### Steps to Reproduce and Observed Behavior
When I try to run `std.log.info` after `glfwinit`...
```zig
const std = @import("std");
const c = @cImport(@cInclude("GLFW/glfw3.h"));
pub fn main() void {
// std.debug.print("", .{}); // Somehow this fixes it?
_ = c.glfwInit();
std.log.info("Hello", .{}); // PANIC
}
```
```bash
zig build-exe repro.zig -lc -lglfw && ./repro
```
panics with:
```
thread 114247 panic: attempt to use null value
aborting due to recursive panic
fish: Job 2, './repro' terminated by signal SIGABRT (Abort)
```
From what i saw it panics at
https://codeberg.org/ziglang/zig/src/branch/master/lib/std/Io/Threaded.zig#L13214
I have no experience in zig's codebase. My guess is it has something to do with environment
```bash
LD_DEBUG=bindings ./repro 2>&1 | grep setenv
```
there are a few `setenv`s which might cause relocation as many c libraries do like `glfw` ... and from I could tell, the environment pointer is stored at the [start](https://codeberg.org/ziglang/zig/src/branch/master/lib/std/start.zig#L625 ) might go stale when [scanEnviron](https://codeberg.org/ziglang/zig/src/branch/master/lib/std/Io/Threaded.zig#L13134-L13139) tries to read it. That's why I assume `std.debug.print` before it fixes it. because then `scanEnviron` exits early once initlialized...
Not sure though : ) just eyeballed it.
### Expected Behavior
There is should be no panic, it didn't happen before in zig so I assume this a regression.