Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: found bad pointer in Go heap #55040

Closed
tapesource opened this issue Sep 13, 2022 · 3 comments
Closed

runtime: found bad pointer in Go heap #55040

tapesource opened this issue Sep 13, 2022 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.

Comments

@tapesource
Copy link

tapesource commented Sep 13, 2022

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

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Sep 13, 2022
@cuonglm
Copy link
Member

cuonglm commented Sep 13, 2022

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

@cuonglm cuonglm closed this as completed Sep 13, 2022
@tapesource
Copy link
Author

tapesource commented Sep 13, 2022

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

@cuonglm
Copy link
Member

cuonglm commented Sep 13, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Development

No branches or pull requests

3 participants