runtime,testing: FATAL: ThreadSanitizer CHECK failed: ./gotsan.cpp:6945 "((kBlockMagic)) == ((((u64*)addr)[0]))"

[cuonglm]

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

$ go version
go version devel +8054b13536 Thu Nov 28 15:16:27 2019 +0000 darwin/amd64

Does this issue reproduce with the latest release?

No

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

go env Output

$ go env
GO111MODULE="off"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/cuonglm/Library/Caches/go-build"
GOENV="/Users/cuonglm/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/cuonglm/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/cuonglm/sources/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/cuonglm/sources/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/y4/hs76ltbn7sb66lw_6934kq4m0000gn/T/go-build276429327=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

$ go get -d github.com/loadimpact/k6
$ cd $GOPATH/src/github.com/loadimpact/k6/stats/csv
$ go test -count=10 -race

What did you expect to see?

Test passes.

What did you see instead?

FATAL: ThreadSanitizer CHECK failed: ./gotsan.cpp:6945 "((kBlockMagic)) == ((((u64*)addr)[0]))" (0x6a6cb03abcebc041, 0x1096b02)
exit status 66
FAIL	github.com/loadimpact/k6/stats/csv	1.426s

• This seems to be a regression of runtime: ThreadSanitizer CHECK failed #27660.
• git bisect points to 2d8c199 (I have no idea why)

cc @ianlancetaylor

[cuonglm]

Another error:

$ go test -count=2 -race
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x32ffb60 pc=0x1024e20]

runtime stack:
runtime.throw(0x195de24, 0x2a)
	/Users/cuonglm/sources/go/src/runtime/panic.go:1106 +0x72
runtime.sigpanic()
	/Users/cuonglm/sources/go/src/runtime/signal_unix.go:661 +0x46a

goroutine 1 [chan receive]:
testing.(*T).Run(0xc0001565a0, 0x194ef84, 0xe, 0x1a307d0, 0x1)
	/Users/cuonglm/sources/go/src/testing/testing.go:1006 +0x699
testing.runTests.func1(0xc0001565a0)
	/Users/cuonglm/sources/go/src/testing/testing.go:1247 +0xa7
testing.tRunner(0xc0001565a0, 0xc00012fd50)
	/Users/cuonglm/sources/go/src/testing/testing.go:954 +0x1ec
testing.runTests(0xc000136940, 0x20dfa40, 0xb, 0xb, 0x0)
	/Users/cuonglm/sources/go/src/testing/testing.go:1245 +0x528
testing.(*M).Run(0xc0001d6100, 0x0)
	/Users/cuonglm/sources/go/src/testing/testing.go:1162 +0x300
main.main()
	_testmain.go:64 +0x224

goroutine 33 [select]:
github.com/loadimpact/k6/stats/csv.(*Collector).Run(0xc00014f900, 0x1b05fa0, 0xc000162cc0)
	/Users/cuonglm/go/src/github.com/loadimpact/k6/stats/csv/collector.go:128 +0x160
github.com/loadimpact/k6/stats/csv.TestRunCollect.func1(0xc00014f900, 0x1b05fa0, 0xc000162cc0, 0xc00049b6a0)
	/Users/cuonglm/go/src/github.com/loadimpact/k6/stats/csv/collector_test.go:281 +0x4d
created by github.com/loadimpact/k6/stats/csv.TestRunCollect
	/Users/cuonglm/go/src/github.com/loadimpact/k6/stats/csv/collector_test.go:280 +0xc60

goroutine 32 [sleep]:
time.Sleep(0x3b9aca00)
	/Users/cuonglm/sources/go/src/runtime/time.go:193 +0xba
github.com/loadimpact/k6/stats/csv.TestRunCollect(0xc0001578c0)
	/Users/cuonglm/go/src/github.com/loadimpact/k6/stats/csv/collector_test.go:287 +0xcf0
testing.tRunner(0xc0001578c0, 0x1a307d0)
	/Users/cuonglm/sources/go/src/testing/testing.go:954 +0x1ec
created by testing.(*T).Run
	/Users/cuonglm/sources/go/src/testing/testing.go:1005 +0x661
exit status 2
FAIL	github.com/loadimpact/k6/stats/csv	0.533s

[randall77]

I can reproduce the first error on linux/amd64.
It doesn't seem to fail with 1.13.

Presumably this is a bug in the tsan C++ library. It looks like a memory overwrite. The code is checking that the header of the memory block has not been clobbered between allocation and free, and it has been clobbered.

I don't see anything in the tsan tracker that might be a fix for this, after we forked it at 810ae8ddac890a6613d814c0b5415c7fcb7f5cca. But I'm not sure about that.

@dvyukov

[cuonglm]

@randall77 it's only failed after 2d8c199

[ianlancetaylor]

I have a fix.

[gopherbot]

Change https://golang.org/cl/209580 mentions this issue: runtime: use current P's race context in timer code