runtime: linux programs built with -gc=conservative or -gc=precise at -opt=0 crash before main #5823

On linux, every program built with -gc=conservative or -gc=precise at -opt=0 crashes before main runs. This is possibly exposed by commit 82decca, which moved initRand() before initHeap(). This blocks #5822.

package main

func main() { println("ok") }

$ tinygo build -o ok -gc=conservative -opt=0 ok.go && ./ok
panic: runtime error: invalid memory address or nil pointer dereference
[tinygo: panic at .../src/runtime/runtime_unix.go]

With -scheduler=none or -scheduler=tasks it crashes. With -scheduler=threads it hangs with no output. testdata/gc.go behaves the same way. Boehm, -opt=1 and darwin are not affected.

Cause

hardwareRand (src/runtime/os_linux.go:50) passes &n to getrandom. Because its address is taken, the compiler allocates n with runtime.alloc. Only OptimizeAllocs moves it back to the stack, and that pass does not run at -opt=0.

initRand calls hardwareRand before initHeap, so this allocation happens before the heap exists. setHeapEnd then memcpys from a nil metadataStart:

memcpy
runtime.setHeapEnd   gc_blocks.go:377
runtime.growHeap     runtime_unix.go:361
runtime.alloc
runtime.hardwareRand os_linux.go:50
runtime.initRand     algorithm.go:27
runtime.run          scheduler_none.go:25

With -scheduler=threads, alloc takes gcLock and calls runGC, which calls GCStopWorldAndScan and then task.Current. task.Init has not run yet, so task.Current calls runtimeFatal. Printing that message allocates, and the new allocation blocks forever on gcLock.

Windows hardwareRand (runtime_windows.go:289) has the same pattern. I have not tested it.

Reproduced on linux/amd64 (LLVM 22, dev f6d269f) in qemu.