runtime: found bad pointer in Go heap

[tapesource]

What version of Go are you using (go version)?

$ go version
go version go1.19 darwin/arm64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="arm64"
GOBIN=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOOS="darwin"
GOVERSION="go1.19"
GCCGO="gccgo"

What did you do?

When re-allocating a slice shared by two goroutines, the reference to the obsolete slice seems to get lost, thus the GC throws a fatal error.
See simplified example
https://go.dev/play/p/QGhbGY657Tn

What did you expect to see?

The program shouldn't stop due to a fatal error, but the content of the slice should be unreliable.

What did you see instead?

The runtime stops due to a fatal error.

runtime: pointer 0xc0002c9fe0 to unused region of span span.base()=0xc0002c8000 span.limit=0xc0002c9fe0 span.state=1
fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)

runtime stack:
runtime.throw({0x469e6a?, 0x42189a?})
/usr/local/go-faketime/src/runtime/panic.go:1047 +0x5d fp=0xc000091ee0 sp=0xc000091eb0 pc=0x42d71d
runtime.badPointer(0x7f2391683040, 0x0?, 0x0, 0x2000?)
/usr/local/go-faketime/src/runtime/mbitmap.go:373 +0x150 fp=0xc000091f30 sp=0xc000091ee0 pc=0x40e310
runtime.findObject(0xc000026f00?, 0xc000091fb8?, 0x420da5?)
/usr/local/go-faketime/src/runtime/mbitmap.go:416 +0xa6 fp=0xc000091f68 sp=0xc000091f30 pc=0x40e4a6
runtime.wbBufFlush1(0xc000026f00)
/usr/local/go-faketime/src/runtime/mwbbuf.go:260 +0xe5 fp=0xc000091fb0 sp=0xc000091f68 pc=0x429465
runtime.wbBufFlush.func1()
/usr/local/go-faketime/src/runtime/mwbbuf.go:201 +0x25 fp=0xc000091fc8 sp=0xc000091fb0 pc=0x4292a5
runtime.systemstack()
/usr/local/go-faketime/src/runtime/asm_amd64.s:492 +0x49 fp=0xc000091fd0 sp=0xc000091fc8 pc=0x454589

goroutine 1 [running]:
runtime.systemstack_switch()
/usr/local/go-faketime/src/runtime/asm_amd64.s:459 fp=0xc0002dee58 sp=0xc0002dee50 pc=0x454520
runtime.wbBufFlush(0x7f23b894cf18?, 0xa0?)
/usr/local/go-faketime/src/runtime/mwbbuf.go:200 +0x6c fp=0xc0002dee78 sp=0xc0002dee58 pc=0x42932c
runtime.wbBufFlush(0xc000010018, 0xc00038ae10)
:1 +0x2a fp=0xc0002dee98 sp=0xc0002dee78 pc=0x456a4a
runtime.gcWriteBarrier()
/usr/local/go-faketime/src/runtime/asm_amd64.s:1692 +0xa3 fp=0xc0002def18 sp=0xc0002dee98 pc=0x4549e3
runtime.gcWriteBarrierDX()
/usr/local/go-faketime/src/runtime/asm_amd64.s:1720 +0x7 fp=0xc0002def20 sp=0xc0002def18 pc=0x454a67
main.main.func1(...)
/tmp/sandbox1460122604/prog.go:12
main.main()
/tmp/sandbox1460122604/prog.go:18 +0x132 fp=0xc0002def80 sp=0xc0002def20 pc=0x4578b2
runtime.main()
/usr/local/go-faketime/src/runtime/proc.go:250 +0x1fe fp=0xc0002defe0 sp=0xc0002def80 pc=0x42fefe
runtime.goexit()
/usr/local/go-faketime/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc0002defe8 sp=0xc0002defe0 pc=0x454901

[cuonglm]

Your program has data race, 2 goroutines attempt to modify the same slice without synchronization.

[tapesource]

Yes, so I would expect the data to be corrupted, but not the runtime to stop.

[cuonglm]

Yes, so I would expect the data to be corrupted, but not the runtime to stop.

A racy program is invalid in Go, you can run with -race to get nicer report.