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.
Go version
go version go1.21.1 darwin/amd64
Output of
go envin your module/workspace:What did you do?
go test -race ./...on the attached projectraceAlloc.zip
What did you see happen?
Saw the race report that is included in
result.txtWhat did you expect to see?
Expect to see the call stack that allocated the object
itemsin addition to the call stack of the two conflicting access.This is a proposal/feature request.
In complex projects when we run tests with
-raceoption 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.