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: memory corruption after append to huge slice #29495

as opened this issue Jan 2, 2019 · 4 comments


None yet
3 participants
Copy link

commented Jan 2, 2019

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

GOARCH=386 golang:1.11.4-alpine and golang:1.12-rc-stretch

What did you do?

package main
import "fmt"
func main() {
	size := 1<<31 - 1
	z := p(make([]byte, size, size))
	z = p(append(z, 'a'))
	z[0] = 'q'
	z = p(append(z, 'b'))
func p(b []byte) []byte {
	fmt.Printf("%p len(%d) cap(%d) first(%x) last(%x)\n", b, len(b), cap(b), b[0], b[len(b)-1])
	return b

What did you expect to see?

An out of range panic

What did you see instead?

0x29000000 len(2147483647) cap(2147483647) first(0) last(0)
0x29000000 len(-2147483648) cap(2147483647) first(0) last(61)
unexpected fault address 0xa9000000
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0xa9000000 pc=0x80be8bc]

goroutine 1 [running]:
runtime.throw(0x80e38de, 0x5)
	/go/src/runtime/panic.go:608 +0x6a fp=0x8c7364c sp=0x8c73638 pc=0x806b39a
	/go/src/runtime/signal_unix.go:397 +0x1c2 fp=0x8c73670 sp=0x8c7364c pc=0x807c712
	/g/src/ +0x9c fp=0x8c73698 sp=0x8c73670 pc=0x80be8bc
	/g/src/ +0x28 fp=0x8c73fd0 sp=0x8c73698 pc=0x80be988
	/go/src/runtime/proc.go:201 +0x206 fp=0x8c73ff0 sp=0x8c73fd0 pc=0x806cb66
	/go/src/runtime/asm_386.s:1324 +0x1 fp=0x8c73ff4 sp=0x8c73ff0 pc=0x80903f1
exit status 2

This comment has been minimized.

Copy link

commented Jan 2, 2019

Not sure what the exact go1.12 tested is but a similar issue was fixed in #29190 in December.

Could you try to reproduce this on tip?


This comment has been minimized.

Copy link

commented Jan 2, 2019

@martisch I can't reproduce with:

$ go version
go version devel +9b776f32fb Sun Dec 30 01:26:02 2018 +0700 linux/amd64

This comment has been minimized.

Copy link

commented Jan 2, 2019

@gnouc thanks, was that tested with GOARCH=386? (I cant get my go darwin/amd64 to allocate the slice in the first place with GOARCH=386)


This comment has been minimized.

Copy link
Contributor Author

commented Jan 2, 2019

This is fixed on tip (with GOARCH=386), unfortunately the dates on the latest beta lead me to believe otherwise. at first. Closing.

@as as closed this Jan 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.