proposal: cmd/compile,runtime: `-race` should report the allocation site of the object involved in the data race

[chabbimilind]

Go version

go version go1.21.1 darwin/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/Users/xx/Library/Caches/go-build'
GOENV='/Users/xx/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/xx/gocode/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/milind/gocode'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/Cellar/go/1.21.1/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/Cellar/go/1.21.1/libexec/pkg/tool/darwin_amd64'
GOVCS=''
GOVERSION='go1.21.1'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/Users/xx/Projects/GoExamples/raceAlloc/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/rz/d0xs6gz11nl81r1thdl4g8gm0000gn/T/go-build271399794=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

go test -race ./... on the attached project
raceAlloc.zip

What did you see happen?

Saw the race report that is included in result.txt

What did you expect to see?

Expect to see the call stack that allocated the object items in addition to the call stack of the two conflicting access.

This is a proposal/feature request.

In complex projects when we run tests with -race option and the tests fail, we get large call stacks. Many times the data race is not in the project code but because of shared objects created within tests; and in such cases the fix is also, often, in the test code.

We often see this issue in our CI systems. It is nontrivial for developers to debug data races purely from the two conflicting call stacks that access the shared object. It would be much better if we can show where the object in race was allocated.

This feature exists in the CilkSan (openCIlk) language's race detection capabilities.

[ianlancetaylor]

CC @dvyukov

[dvyukov]

Well, this is #6690 :)

Technically all bits are there. TSan supported alloc and mutex stacks always. It just needs to be wired and printed in reports.
However, it may increase memory consumption to some degree.