runtime: lock ordering problem on Windows reported by GOEXPERIMENT=staticlockranking in syscall_windows.go map use #76058
Description
Go version
go version go1.26-devel_12ec09f Sat Oct 25 06:33:03 2025 -0700 windows/amd64
Output of go env in your module/workspace:
...What did you do?
I initially guessed this failure was likely a problem I had introduced with unmerged changes to mem_windows.go or os_windows.go for my runtime.free work (#74299), but it is reproducible on tip without my changes:
> gotip download
> set GOEXPERIMENT=staticlockranking
> gotip test runtime
What did you see happen?
Failure with lock ordering problem reported:
0 ======
0 : LEAF 1000 0x7ff632ed1ba0
1 : fin 40 0x7ff632ef9310
fatal error: lock ordering problem
runtime stack:
runtime.throw({0x7ff632aba217?, 0x0?})
.../sdk/gotip/src/runtime/panic.go:1227 +0x4d fp=0xc4687ff578 sp=0xc4687ff548 pc=0x7ff6325ae38d
runtime.checkRanks(0x7ff632ea8300, 0xc4687ff698?, 0x7ff632591385?)
.../sdk/gotip/src/runtime/lockrank_on.go:166 +0x216 fp=0xc4687ff5d8 sp=0xc4687ff578 pc=0x7ff63252c616
runtime.lockWithRankMayAcquire.func1()
.../sdk/gotip/src/runtime/lockrank_on.go:245 +0x7f fp=0xc4687ff608 sp=0xc4687ff5d8 pc=0x7ff63252ccbf
runtime.lockWithRankMayAcquire(0x0?, 0xc4687ff6c0?)
.../sdk/gotip/src/runtime/lockrank_on.go:234 +0x48 fp=0xc4687ff640 sp=0xc4687ff608 pc=0x7ff63252cc08
runtime.lockRankMayQueueFinalizer(...)
.../sdk/gotip/src/runtime/mfinal.go:98
runtime.mallocgcSmallScanNoHeaderSC5(0x30, 0x7ff632a8ed80, 0xb2?)
.../sdk/gotip/src/runtime/malloc_generated.go:650 +0x33 fp=0xc4687ff6b8 sp=0xc4687ff640 pc=0x7ff632530933
runtime.mallocgc(0x0?, 0xc4687ff728?, 0xd9?)
.../sdk/gotip/src/runtime/malloc.go:1129 +0x51 fp=0xc4687ff6e8 sp=0xc4687ff6b8 pc=0x7ff6325ab951
runtime.newobject(0x7ff632ea8300?)
.../sdk/gotip/src/runtime/malloc.go:1870 +0x25 fp=0xc4687ff710 sp=0xc4687ff6e8 pc=0x7ff63252f325
internal/runtime/maps.NewEmptyMap(...)
.../sdk/gotip/src/internal/runtime/maps/map.go:332
runtime.makemap_small()
.../sdk/gotip/src/runtime/map.go:44 +0x1a fp=0xc4687ff738 sp=0xc4687ff710 pc=0x7ff6325abcda
syscall.compileCallback({0x7ff632a05ea0?, 0x7ff632ae79e0?}, 0xd0?)
.../sdk/gotip/src/runtime/syscall_windows.go:329 +0x2b7 fp=0xc4687ff838 sp=0xc4687ff738 pc=0x7ff6325b1c57
runtime.goenvs()
.../sdk/gotip/src/runtime/os_windows.go:529 +0x1bd fp=0xc4687ff8b0 sp=0xc4687ff838 pc=0x7ff63256b19d
runtime.schedinit()
.../sdk/gotip/src/runtime/proc.go:889 +0x23f fp=0xc4687ff900 sp=0xc4687ff8b0 pc=0x7ff63257373f
runtime.rt0_go()
.../sdk/gotip/src/runtime/asm_amd64.s:365 +0x13c fp=0xc4687ff908 sp=0xc4687ff900 pc=0x7ff6325b3f7c
FAIL runtime 0.055s
FAIL
What did you expect to see?
No lock ordering problem.
It might be that the syscall setup on Windows is not properly declaring needed lock ranks (perhaps the call back store lock?), or perhaps there is something else going on.
I did not dig in here.