runtime: cannot allocate memory testing x/sys/unix on linux-386-stretch

[bcmills]

fatal error: runtime: cannot allocate memory

runtime stack:
runtime.throw({0x81f0ae5, 0x1f})
	/workdir/go/src/runtime/panic.go:1000 +0x6a
runtime.persistentalloc1(0x3fc0, 0x0, 0x832f100)
	/workdir/go/src/runtime/malloc.go:1369 +0x251
runtime.persistentalloc.func1()
	/workdir/go/src/runtime/malloc.go:1322 +0x35
runtime.persistentalloc(0x3fc0, 0x0, 0x832f100)
	/workdir/go/src/runtime/malloc.go:1321 +0x5e
runtime.(*fixalloc).alloc(0x8323fb4)
	/workdir/go/src/runtime/mfixalloc.go:89 +0x7d
runtime.(*mheap).allocMSpanLocked(0x831fa80)
	/workdir/go/src/runtime/mheap.go:1068 +0xba
runtime.(*mheap).allocSpan(0x831fa80, 0x1, 0x0, 0xc)
	/workdir/go/src/runtime/mheap.go:1185 +0x1ff
runtime.(*mheap).alloc.func1()
	/workdir/go/src/runtime/mheap.go:913 +0x82
runtime.systemstack()
	/workdir/go/src/runtime/asm_386.s:370 +0x41

goroutine 1 [running]:
runtime.systemstack_switch()
	/workdir/go/src/runtime/asm_386.s:337 fp=0x903fb7c sp=0x903fb78 pc=0x80acec0
runtime.(*mheap).alloc(0x831fa80, 0x1, 0xc)
	/workdir/go/src/runtime/mheap.go:907 +0x5f fp=0x903fb9c sp=0x903fb7c pc=0x806e4cf
runtime.(*mcentral).grow(0x83201b4)
	/workdir/go/src/runtime/mcentral.go:244 +0x62 fp=0x903fbc0 sp=0x903fb9c pc=0x805d4f2
runtime.(*mcentral).cacheSpan(0x83201b4)
	/workdir/go/src/runtime/mcentral.go:164 +0xef fp=0x903fbfc sp=0x903fbc0 pc=0x805d0af
runtime.(*mcache).refill(0xf7d70538, 0xc)
	/workdir/go/src/runtime/mcache.go:162 +0x91 fp=0x903fc20 sp=0x903fbfc pc=0x805c931
runtime.(*mcache).nextFree(0xf7d70538, 0xc)
	/workdir/go/src/runtime/malloc.go:812 +0x81 fp=0x903fc40 sp=0x903fc20 pc=0x8054481
runtime.mallocgc(0x38, 0x81df840, 0x1)
	/workdir/go/src/runtime/malloc.go:1011 +0x3ea fp=0x903fc88 sp=0x903fc40 pc=0x8054a0a
runtime.newobject(0x81df840)
	/workdir/go/src/runtime/malloc.go:1185 +0x2c fp=0x903fc9c sp=0x903fc88 pc=0x8054edc
runtime.acquireSudog()
	/workdir/go/src/runtime/proc.go:402 +0x24e fp=0x903fcd4 sp=0x903fc9c pc=0x808171e
runtime.chanrecv(0x90a6800, 0x903fd53, 0x1)
	/workdir/go/src/runtime/chan.go:563 +0x21e fp=0x903fd1c sp=0x903fcd4 pc=0x804e8fe
runtime.chanrecv1(0x90a6800, 0x903fd53)
	/workdir/go/src/runtime/chan.go:442 +0x1c fp=0x903fd30 sp=0x903fd1c pc=0x804e6dc
testing.(*T).Run(0x9006ff0, {0x81ea5d7, 0xc}, 0x81f7aa8)
	/workdir/go/src/testing/testing.go:1497 +0x393 fp=0x903fd7c sp=0x903fd30 pc=0x811b433
testing.runTests.func1(0x9006ff0)
	/workdir/go/src/testing/testing.go:1849 +0x5e fp=0x903fda0 sp=0x903fd7c pc=0x811d28e
testing.tRunner(0x9006ff0, 0x903fe38)
	/workdir/go/src/testing/testing.go:1449 +0x113 fp=0x903fde8 sp=0x903fda0 pc=0x811a6b3
testing.runTests(0x9012090, {0x8316880, 0x4f, 0x4f}, {0xc091f54b8daabad8, 0x8bb2cde8bc, 0x8318c20})
	/workdir/go/src/testing/testing.go:1847 +0x3a6 fp=0x903fe4c sp=0x903fde8 pc=0x811d176
testing.(*M).Run(0x90000a0)
	/workdir/go/src/testing/testing.go:1729 +0x67b fp=0x903ff88 sp=0x903fe4c pc=0x811bd0b
main.main()
	_testmain.go:205 +0x185 fp=0x903ffc4 sp=0x903ff88 pc=0x81ae255
runtime.main()
	/workdir/go/src/runtime/proc.go:250 +0x24d fp=0x903fff0 sp=0x903ffc4 pc=0x808100d
runtime.goexit()
	/workdir/go/src/runtime/asm_386.s:1326 +0x1 fp=0x903fff4 sp=0x903fff0 pc=0x80ae391

goroutine 109 [running]:
	goroutine running on other thread; stack unavailable
created by testing.(*T).Run
	/workdir/go/src/testing/testing.go:1496 +0x374
FAIL	golang.org/x/sys/unix	0.115s

greplogs --dashboard -md -l -e '(?ms)\Alinux-386.*^fatal error: runtime: cannot allocate memory'

2022-04-26T02:28:58-9388b58-17d7983/linux-386-stretch

[bcmills]

This failure seems very odd to me because there's hardly anything going on in the goroutine dump that would explain an OOM.

Moreover, this is the only one of these in the logs — it's not clear to me whether this is a recent regression or an existing very-low-probability failure mode.

@golang/runtime: since linux/386 is a first-class port, we should at least check whether this could have been caused by any recent changes.

[ianlancetaylor]

Rolling forward to 1.20. Please comment if you disagree. Thanks.

[bcmills]

Debian Stretch is no longer supported as of June 30, 2022; I've filed #56414 to migrate away from that release.

If we haven't seen this failure mode on any other builders, perhaps we should consider this issue obsolete.

[mknyszek]

Let's do one final check to make sure this hasn't happened again, and if it hasn't I think I'm inclined to close this.

[mknyszek]

I don't see anything for linux/386. windows-arm64-11 has been flaking with a similar error since March, but yeah nothing for linux/386.