Skip to content

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

Open
@chabbimilind

Description

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

image

Activity

changed the title [-][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[/+] on May 7, 2024
added this to the Proposal milestone on May 7, 2024
moved this to Incoming in Proposalson May 7, 2024
ianlancetaylor

ianlancetaylor commented on May 7, 2024

@ianlancetaylor
Contributor
dvyukov

dvyukov commented on May 8, 2024

@dvyukov
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Status

    Incoming

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @dvyukov@ianlancetaylor@gopherbot@chabbimilind

        Issue actions

          proposal: cmd/compile,runtime: `-race` should report the allocation site of the object involved in the data race · Issue #67221 · golang/go