reflect: running go test with -count=2 or greater causes nil pointer dereference panic

[dmitshur]

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

$ ../bin/go version
go version devel +270de1c110 Mon Mar 25 22:41:37 2019 +0000 darwin/amd64

Does this issue reproduce with the latest release?

No, it's not a problem in Go 1.12.1, only on latest master commit.

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

go env Output

$ ../bin/go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/dmitshur/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/dmitshur/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/dmitshur/gotip"
GOTMPDIR=""
GOTOOLDIR="/Users/dmitshur/gotip/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/dmitshur/gotip/src/go.mod"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/3m/rg2zm24d1jg40wb48wr0hdjw00jwcj/T/go-build434087460=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

$ ../bin/go test -count=2 reflect

What did you expect to see?

ok  	reflect	0.896s

What did you see instead?

$ ../bin/go test -count=2 reflect
--- FAIL: TestStructOfWithInterface (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=0x12 pc=0x10af28d]

goroutine 3656 [running]:
testing.tRunner.func1(0xc0000c2400)
	/Users/dmitshur/gotip/src/testing/testing.go:830 +0x391
panic(0x1213f20, 0x1663e20)
	/Users/dmitshur/gotip/src/runtime/panic.go:619 +0x1b2
reflect.name.name(...)
	/Users/dmitshur/gotip/src/reflect/type.go:495
reflect.haveIdenticalUnderlyingType(0xc0000b43f0, 0xc0000b4230, 0xc000117001, 0x11f6c20)
	/Users/dmitshur/gotip/src/reflect/type.go:1661 +0x6fd
reflect.StructOf(0xc0004d2070, 0x1, 0x1, 0x0, 0x0)
	/Users/dmitshur/gotip/src/reflect/type.go:2601 +0x1272
reflect_test.TestStructOfWithInterface(0xc0000c2400)
	/Users/dmitshur/gotip/src/reflect/all_test.go:4922 +0x6d8
testing.tRunner(0xc0000c2400, 0x1260390)
	/Users/dmitshur/gotip/src/testing/testing.go:865 +0xbf
created by testing.(*T).Run
	/Users/dmitshur/gotip/src/testing/testing.go:916 +0x350
FAIL	reflect	0.874s

[dmitshur]

This is a regression. It doesn't happen in Go 1.12.1:

$ go version
go version go1.12.1 darwin/amd64
$ go test -count=2 reflect
ok  	reflect	0.915s

[cespare]

I'm bisecting...

[cespare]

This was also caused by db16de9 (CL 169157), same as #31039.

/cc @randall77

[randall77]

Similar problem here, we're now calling addTypeBits before the ptrdata is initialized, and addTypeBits exits early if ptrdata is zero.

[gopherbot]

Change https://golang.org/cl/169318 mentions this issue: reflect: initialize ptrdata earlier in StructOf