runtime: allocation state broken during runtime init on windows/386 (rare)

[bcmills]

#!watchflakes
post <- goos == "windows" && log ~ `^\s*fatal error: s.allocCount` && log ~ `^\s*runtime\.freezetheworld`

(Pulled out from #52647 (comment).)

From a TryBot run on https://go.dev/cl/518776:

runtime: s.allocCount= 1 s.nelems= 5
fatal error: s.allocCount != s.nelems && freeIndex == s.nelems
fatal error: unexpected signal during runtime execution
panic during panic
[signal 0xc0000005 code=0x0 addr=0x4 pc=0x348aa5]

runtime stack:
runtime.throw({0xcc0608, 0x2a})
	runtime/panic.go:859 +0x4d fp=0x20f998 sp=0x20f984 pc=0x338c6d
runtime.sigpanic()
	runtime/signal_windows.go:358 +0x2bd fp=0x20f9bc sp=0x20f998 pc=0x350c6d
runtime.preemptall()
	runtime/proc.go:5774 +0x35 fp=0x20f9d8 sp=0x20f9bc pc=0x348aa5
runtime.freezetheworld()
	runtime/proc.go:962 +0xd6 fp=0x20f9f0 sp=0x20f9d8 pc=0x33d326
runtime.startpanic_m()
	runtime/panic.go:1113 +0x157 fp=0x20fa04 sp=0x20f9f0 pc=0x3393c7
runtime.fatalthrow.func1()
	runtime/panic.go:1018 +0x2d fp=0x20fa24 sp=0x20fa04 pc=0x3390cd
runtime.fatalthrow(0x2)
	runtime/panic.go:1013 +0x69 fp=0x20fa3c sp=0x20fa24 pc=0x339089
runtime.throw({0xcc4fde, 0x31})
	runtime/panic.go:859 +0x4d fp=0x20fa50 sp=0x20fa3c pc=0x338c6d
runtime.(*mcache).nextFree(...)
	runtime/malloc.go:921
runtime.mallocgc(0x11c0, 0xc8a720, 0x1)
	runtime/malloc.go:1110 +0xbdd fp=0x20fac4 sp=0x20fa50 pc=0x301cad
runtime.newobject(0xc8a720)
	runtime/malloc.go:1322 +0x2a fp=0x20fad8 sp=0x20fac4 pc=0x301dfa
runtime.procresize(0x8)
	runtime/proc.go:5263 +0x367 fp=0x20fb3c sp=0x20fad8 pc=0x3471e7
runtime.schedinit()
	runtime/proc.go:762 +0x208 fp=0x20fb60 sp=0x20fb3c pc=0x33cb38
runtime.rt0_go()
	runtime/asm_386.s:243 +0x15f fp=0x20fb64 sp=0x20fb60 pc=0x37019f
go: error obtaining buildID for go tool compile: exit status 2
go tool dist: Failed logging metadata: exit status 1


Error: tests failed: dist test failed: {go_test:go/types go/types}: exit status 1

[mknyszek]

Wow, that's crashing real early in the runtime. That's literally crashing on one of the first few allocations that happen...

[mknyszek]

I guess given how early that's failing I'm not _super_surprised there's a panic-during-panic; that might be just that something isn't set up yet, or something. But the memory allocator state being busted right at allocation start, that's different and very surprising.

[mknyszek]

This seems to be the compiler crashing very shortly after startup. In triage, we're not really sure if this is actionable at all, since it implies memory corruption extremely early on. There are very few places that could be coming from. If it's reproducible that's one thing, but my understanding is that this has only happened once. We'll wait on more such issues.

[bcmills]

I wonder if it's a bug triggered by a very unlucky ASLR relocation or something along those lines.

(But I agree that it seems fine to wait for more examples before investigating further.)

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)