Open chabbimilind opened 5 months ago
CC @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.
Go version
go version go1.21.1 darwin/amd64
Output of
go env
in your module/workspace:What did you do?
go test -race ./...
on the attached project raceAlloc.zipWhat 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.