go: runtime: ThreadSanitizer CHECK failed
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version
)?
$ go version
go version go1.11 linux/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env
)?
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/benesch/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/benesch/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
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-build445193843=/tmp/go-build -gno-record-gcc-switches"
What did you do?
go get -u github.com/cockroachdb/cockroach
cd $(go env GOPATH)/src/github.com/cockroachdb/cockroach
make testrace PKG=./pkg/sql/logictest TESTS=TestLogic
This builds some C and C++ dependencies and ultimately runs:
go test -race -tags ' make x86_64_linux_gnu' -ldflags '-X github.com/cockroachdb/cockroach/pkg/build.typ=development -extldflags "" -X "github.com/cockroachdb/cockroach/pkg/build.tag=v2.2.0-alpha.00000000-793-g33c7d27d82-dirty" -X "github.com/cockroachdb/cockroach/pkg/build.rev=33c7d27d8216b543ac77f0fe39d440ebebfa9e70" -X "github.com/cockroachdb/cockroach/pkg/build.cgoTargetTriple=x86_64-linux-gnu" ' -run "TestLogic" -timeout 25m ./pkg/sql/logictest
What did you expect to see?
Either a successful test run or an actual race.
What did you see instead?
FATAL: ThreadSanitizer CHECK failed: ./gotsan.cc:380 "((v)) > ((0))" (0x0, 0x0)
I tried to dig into this, but gotsan.cc is apparently generated deep inside the build process for the race detector and it wasn’t clear to me how to generate a gotsan.cc that matched my Go version.
Totally possible that this our (CockroachDB’s) bug, but there’s not a lot here for me to go on, so figured I’d file here and see if someone with more expertise in the race detector had any insight.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 1
- Comments: 54 (47 by maintainers)
Commits related to this issue
- runtime: ensure m.p is never stale When a goroutine enters a syscall, its M unwires from its P to allow the P to be retaken by another M if the syscall is slow. The M retains a reference to its old P... — committed to golang/go by benesch 6 years ago
- runtime/cgo: revise for go1.12 related issues: golang/go#23899, golang/go#28458, golang/go#27660 Update #3 — committed to golang-design/under-the-hood by changkun 5 years ago
Ok, updated the CL to take this approach.