Ask questionsruntime: apparent deadlock in image/gif test on linux-ppc64-buildlet

There was a timeout in the image/gif test, but from the symptoms it looks more like a runtime bug to me: one of the threads is idle on runtime.futex via runtime.mcall, and the the other one says goroutine running on other thread; stack unavailable.

That combination of symptoms is similar to #32327, although the path from runtime.mcall to runtime.futex differs.

PC=0x6be3c m=0 sigcode=0

goroutine 0 [idle]:
runtime.futex(0x2ad150, 0x8000000002, 0x0, 0x0, 0x12000, 0x46d40, 0x46704, 0xc00035e780, 0x46d7c, 0xc0000384c8, ...)
	/tmp/workdir-host-linux-ppc64-osu/go/src/runtime/sys_linux_ppc64x.s:472 +0x1c
runtime.futexsleep(0x2ad150, 0x200046708, 0xffffffffffffffff)
	/tmp/workdir-host-linux-ppc64-osu/go/src/runtime/os_linux.go:44 +0x3c
	/tmp/workdir-host-linux-ppc64-osu/go/src/runtime/lock_futex.go:102 +0x1bc
	/tmp/workdir-host-linux-ppc64-osu/go/src/runtime/proc.go:3119 +0x7c
	/tmp/workdir-host-linux-ppc64-osu/go/src/runtime/asm_ppc64x.s:202 +0x58

goroutine 1 [chan receive, 3 minutes]:
testing.(*T).Run(0xc0000acd00, 0x18dbfc, 0x1b, 0x193748, 0x100000000000349)
	/tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:961 +0x304
	/tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:1207 +0x78
testing.tRunner(0xc0000ac000, 0xc000058d48)
	/tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:909 +0xc8
testing.runTests(0xc00008c080, 0x2a7dc0, 0x18, 0x18, 0x0)
	/tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:1205 +0x27c
testing.(*M).Run(0xc0000a8000, 0x0)
	/tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:1122 +0x158
	_testmain.go:96 +0x130

goroutine 30 [running]:
	goroutine running on other thread; stack unavailable
created by testing.(*T).Run
	/tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:960 +0x2e8

r0   0xdd	r1   0x3fffd047b228
r2   0x8000000000	r3   0x2ad150
r4   0x80	r5   0x2
r6   0x0	r7   0x0
r8   0x0	r9   0x0
r10  0x0	r11  0x0
r12  0x0	r13  0x0
r14  0x1a0b0	r15  0xc000030e78
r16  0x0	r17  0xc000025900
r18  0x0	r19  0x1b4782
r20  0xc000020010	r21  0x2ad840
r22  0x0	r23  0x0
r24  0x8	r25  0x3fff8b55a520
r26  0x3fff8b55a578	r27  0x73
r28  0x72	r29  0x1
r30  0x2ad2a0	r31  0x19bbc
pc   0x6be3c	ctr  0x0
link 0x3a62c	xer  0x0
ccr  0x54400002	trap 0xc00
*** Test killed with quit: ran too long (4m0s).
FAIL	image/gif	240.002s

CC @laboger @aclements @mknyszek @randall77


Answer questions laboger

I have not been able to reproduce this one with GOMAXPROCS=2. It would help to know what is on the stack that is unavailable, is there any way to get that information?


Related questions

cmd/link: segmentation fault during mach-o linking
cmd/go: cannot find module providing package error stops `go get` processing hot 3
vendor/ undefined: errors.Frame ... hot 2
cmd/vet: potential false positive in the "suspect or" check hot 2
cmd/go: needs a better error than "missing dot in first path element" when GOROOT is set incorrectly hot 2
x/xerrors: fails to compile on tip hot 1
cmd/go: `go clean <package>` downloads modules hot 1
cmd/cgo error: runtime: unknown pc 0x7fff5c805b86 hot 1
runtime: crash with "invalid pc-encoded table" hot 1
cmd/link: showing many ld warnings of "building for macOS, but linking in object file" hot 1
runtime: go program crach, it seems fall into infinite loop hot 1
cmd/go: major version without preceding tag must be v0, not v1 - breaks build of hot 1
gollvm: Using External Go Packages with gollvm hot 1
runtime: macOS Sierra builders spinning hot 1
cmd/go: Problem using go modules hot 1
Github User Rank List