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

Len(slice) returns a non-zero positive number, but accessing first element results in panic #42037

Closed
malkhamis opened this issue Oct 17, 2020 · 3 comments

Comments

@malkhamis
Copy link

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

$ go version
go version go1.14.6 linux/amd64

Does this issue reproduce with the latest release?

Yes (go version go1.15.3 linux/amd64)

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/malkhamis/.cache/go-build"
GOENV="/home/malkhamis/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/malkhamis/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/malkhamis/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build485775874=/tmp/go-build -gno-record-gcc-switches"

What did you do?

  1. Have a simple test function as follows:
var v string

func TestPanic(t *testing.T) {
	var slice []string
	go func() {
		slice = append(slice, "hello")
	}()
	for len(slice) <= 0 {
	}
	v = slice[0]
}
  1. Run the test as follows:
go test -run TestPanic -count=1000

What did you expect to see?

Disregarding the data race in the test above, I expected to be able to access the first element in the slice if len(slice) returns a number greater than zero

What did you see instead?

There was a panic about nil pointer dereference although that access can only happen if the length of slice is greater than zero.

--- FAIL: TestPanic (0.00s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x509507]

goroutine 30 [running]:
testing.tRunner.func1.1(0x520d20, 0x6182b0)
	/usr/local/go/src/testing/testing.go:1072 +0x30d
testing.tRunner.func1(0xc00013f980)
	/usr/local/go/src/testing/testing.go:1075 +0x41a
panic(0x520d20, 0x6182b0)
	/usr/local/go/src/runtime/panic.go:969 +0x1b9
_/home/malkhamis/projects/goplay.TestPanic(0xc00013f980)
	/home/malkhamis/projects/goplay/main_test.go:14 +0x67
testing.tRunner(0xc00013f980, 0x54c6a8)
	/usr/local/go/src/testing/testing.go:1123 +0xef
created by testing.(*T).Run
	/usr/local/go/src/testing/testing.go:1168 +0x2b3
exit status 2
FAIL	_/home/malkhamis/projects/goplay	0.006s
@seankhliao
Copy link
Member

This is a nil pointer dereference and not an out of bounds

Most likely caused by the data race where the slice header is only partially written

@malkhamis
Copy link
Author

malkhamis commented Oct 17, 2020

Yes I am aware of that.. the question is: should the slice length be updated to reflect a newly appended item that was not fully appended/written yet?

@ALTree
Copy link
Member

ALTree commented Oct 17, 2020

It doesn't really matter, the program is racy and all kind of corruption can happen. It's not possible to make consistency guarantees on a racy program.

Closing here as this is working as intended.

@ALTree ALTree closed this as completed Oct 17, 2020
@golang golang locked and limited conversation to collaborators Oct 17, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants