go: cmd/compile/internal/types2: runtime.mapassign1 throws in (*Checker.recordScope) during bootstrapping

greplogs --dashboard -md -l -e '^goroutine \d+ .*:\n(?:.+\n\t.*\n)*(?:bootstrap/)cmd/compile/internal/types2'

2022-02-03T16:53:55-bec8a10/windows-386-2008

runtime stack:
runtime.gothrow(0x11cfeb0, 0x2a)
	C:/workdir/src/runtime/panic.go:503 +0x8e fp=0x6fc50 sp=0x6fc38
runtime.sigpanic()
	C:/workdir/src/runtime/os_windows.go:36 +0x65 fp=0x6fc70 sp=0x6fc50
scanblock(0xc0833fc000, 0x1c4000, 0x0)
	C:/workdir/src/runtime/mgc0.c:311 +0xab0 fp=0x6fdb0 sp=0x6fc70
gc(0x6fee8)
	C:/workdir/src/runtime/mgc0.c:1440 +0x28b fp=0x6fec8 sp=0x6fdb0
runtime.gc_m()
	C:/workdir/src/runtime/mgc0.c:1368 +0x103 fp=0x6ff00 sp=0x6fec8
runtime.onM(0x169a5b0)
	C:/workdir/src/runtime/asm_amd64.s:257 +0x6d fp=0x6ff08 sp=0x6ff00
runtime.mstart()
	C:/workdir/src/runtime/proc.c:818 fp=0x6ff10 sp=0x6ff08

goroutine 1 [garbage collection]:
runtime.switchtoM()
	C:/workdir/src/runtime/asm_amd64.s:198 fp=0xc0834e6a80 sp=0xc0834e6a78
runtime.gogc(0x0)
	C:/workdir/src/runtime/malloc.go:469 +0x1d6 fp=0xc0834e6ab8 sp=0xc0834e6a80
runtime.mallocgc(0x34000, 0xf97360, 0x0, 0x401f89)
	C:/workdir/src/runtime/malloc.go:341 +0x398 fp=0xc0834e6b68 sp=0xc0834e6ab8
runtime.newarray(0xf97360, 0x400, 0x1aba10)
	C:/workdir/src/runtime/malloc.go:365 +0xc8 fp=0xc0834e6ba0 sp=0xc0834e6b68
runtime.hashGrow(0xe158a0, 0xc0823c9230)
	C:/workdir/src/runtime/hashmap.go:744 +0x8d fp=0xc0834e6bd0 sp=0xc0834e6ba0
runtime.mapassign1(0xe158a0, 0xc0823c9230, 0xc0834e6c98, 0xc0834e6c90)
	C:/workdir/src/runtime/hashmap.go:456 +0x56f fp=0xc0834e6c70 sp=0xc0834e6bd0
bootstrap/cmd/compile/internal/types2.(*Checker).recordScope(0xc08200e380, 0x1506d8, 0xc0825466e0, 0xc0834a6a10)
	C:/workdir/go/src/cmd/compile/internal/types2/check.go:580 +0xa6 fp=0xc0834e6cb0 sp=0xc0834e6c70

2021-09-07T14:53:41-21de6bc/linux-amd64-clang

(attn @griesemer, @findleyr)

About this issue

Original URL
State: open
Created 2 years ago
Comments: 18 (18 by maintainers)

Most upvoted comments

Given #44505 — and assuming that it actually happens within the not-too-distant future — if we are reasonably confident that this is a Go 1.4 bug it might not be worth spending too much time on.

(External Go users who want to build from source can already work around a Go 1.4 bug by bootstrapping from a newer Go version instead.)

bcmills on Feb 3, 2022

I’m pretty sure the last zero-sized field thing was added in Go 1.5 for #9401.

ianlancetaylor on Feb 3, 2022

Do we know for certain that it’s a single 36864-byte object, or could it be multiple objects taking up that much space?

I don’t think we do. This span is in range for being a small object span and it’s within tail waste bounds. It’s hard to say at this point what it was since the size class wasn’t dumped.

mknyszek on Feb 3, 2022

I’m inclined to say this is a Go 1.4 compiler (or runtime) bug. It certainly wouldn’t be the first time we’ve been bit by the Go 1.4 toolchain when enabling new code in the compiler. E.g., this is why we currently disable inlining during bootstrapping:

https://github.com/golang/go/blob/896df422a7cecbace10f5877beeeb1476b6061ae/src/cmd/dist/buildtool.go#L199-L201

mdempsky on Feb 3, 2022