Description
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.

Metadata
Metadata
Assignees
Type
Projects
Status
Activity
[-][proposal] race: data race should report the allocation site of the object involved in the data race[/-][+]proposal: cmd/compile,runtime: `-race` should report the allocation site of the object involved in the data race[/+]ianlancetaylor commentedon May 7, 2024
CC @dvyukov
dvyukov commentedon May 8, 2024
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.