fatal error: runtime-unlock: lock count, followed by stacktrace

[edsantiago]

Only one seen so far, but that's one too many for me. In f37 root remote:

  podman run hostname test
 # podman-remote [options] run --rm quay.io/libpod/alpine:latest printenv HOSTNAME
fatal error: runtime-lock: lock count
fatal error: runtime?unlock: lock count    <----- hundreds, maybe thousands of these lines
     [.....] then back to "lock" (vs many unlock), then:
         panic during panic
         
         runtime stack:
         runtime.throw({0x17ca42b?, 0x7efdf1e3fa10?})
         	/usr/lib/golang/src/runtime/panic.go:1047 +0x5d fp=0x7efdf1e3f9e8 sp=0x7efdf1e3f9b8 pc=0x4445fd
         runtime.unlock2(0x1b?)
         	/usr/lib/golang/src/runtime/lock_futex.go:127 +0x7a fp=0x7efdf1e3fa08 sp=0x7efdf1e3f9e8 pc=0x4188ba
         runtime.unlockWithRank(...)
         	/usr/lib/golang/src/runtime/lockrank_off.go:32
         runtime.unlock(...)
         	/usr/lib/golang/src/runtime/lock_futex.go:112
         runtime.printunlock()
         	/usr/lib/golang/src/runtime/print.go:80 +0x3b fp=0x7efdf1e3fa20 sp=0x7efdf1e3fa08 pc=0x44601b
         runtime.throw.func1()
         	/usr/lib/golang/src/runtime/panic.go:1044 +0x55 fp=0x7efdf1e3fa50 sp=0x7efdf1e3fa20 pc=
         0x444675goroutine 
         95runtime.throw [(running{]:
         0x17ca42b?runtime.throw, (0x7efdf1e3faa8{?0x17c522a}?)
         , 	0x1507060/usr/lib/golang/src/runtime/panic.go?:}1043)
          +	0x46/usr/lib/golang/src/runtime/panic.go fp=:0x7efdf1e3fa801047 sp= +0x7efdf1e3fa500x5d pc= fp=0x4445e60xc000743dc8
          sp=runtime.unlock20xc000743d98( pc=0x1b0x4445fd?
         )
         runtime.lock2	(/usr/lib/golang/src/runtime/lock_futex.go0x0:?127)
          +	0x7a/usr/lib/golang/src/runtime/lock_futex.go fp=:0x7efdf1e3faa055 sp= +0x7efdf1e3fa800x178 pc= fp=0x4188ba0xc000743e08
          sp=runtime.unlockWithRank0xc000743dc8(...)
          pc=	0x4187d8/usr/lib/golang/src/runtime/lockrank_off.go
         :runtime.lockWithRank32(...)
[many many many more lines]

[mheon]

golang/go#56309 could be the issue - we make extensive use of LockOSThread()

[Luap99]

Looking at this, I assume this will be fixed with the next image update because it will contain a newer golang.

[vrothberg]

Yes that makes sense. CI VMs are using Go 1.19.2. The fix for the issue is in .3.

@edsantiago do you want to keep the issue open until the VMs are updated?

[edsantiago]

I'll close: we already have strong incentives to bump VMs, having this issue dangle is only going to cause more work later on.

One request: can someone confirm that 4.4 will be built with a fixed golang?

Thanks @Luap99, @vrothberg.

[vrothberg]

One request: can someone confirm that 4.4 will be built with a fixed golang?

Yes, F37 is on 1.19.5.