-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile/internal: DATA RACE if -coverprofile
flag is provided
#56370
Comments
What makes you think that this is not a valid data race in your code? The two writes which are racing are both in your code, and your tests are calling your code in parallel. So that seems like a valid race to me. |
Hi @mvdan ! I'm not sure if I get your point 🤔 Which writes you're referring to? In the example, I'm just doing assignments (using Blank Identifier). My assumption is based on the fact that all of the variables that I'm assigning are local variables. Also, as I said below, the data race happens only when the code coverage is measured. |
I see, I hadn't noticed how innocent the New function is. It's not writing to any shared memory by design, as far as I can tell. Perhaps you're right that it's the instrumentation. cc @thanm |
Thanks, I'll take a look. |
No worries, if that makes sense, I've put the example into the CI just for the sake of clarity https://github.com/olegbespalov/race/actions/runs/3297314972/jobs/5437986048 |
OK, I can see the issue, will send a fix later this morning. Thanks for the report. |
Change https://go.dev/cl/444617 mentions this issue: |
This patch fixes a problem in which we can get a data race on a coverage counter function registration sequence. The scenario is that package P contains a function F that is built with coverage, then F is inlined into some other package that isn't being instrumented. Within F's exported function body counter updates were being done with atomics, but the initial registration sequence was not, which had the potential to trigger a race. Fix: if race mode is enabled and we're using atomics for counter increments, also use atomics in the registration sequence. Fixes golang#56370. Change-Id: If274b61714b90275ff95fc6529239e9264b0ab0c Reviewed-on: https://go-review.googlesource.com/c/go/+/444617 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Than McIntosh <thanm@google.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Not from my experience
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Run
On the package that
filter
filter.go
filter_test.go
My
go.mod
, just in caseWhat did you expect to see?
No data races
What did you see instead?
A race was detected.
race trace stack
So this is around for a week or so in our CI. I tried to
git bisect
, and it showed me that this commit 4a459cb is the one where it started, but maybe I'm wrong here 🤷If I run the go test without
-coverprofile
flag, no data race appears.$ gotip test --count=1 -race ./... ok github.com/olegbespalov/race/filter 0.021s
The text was updated successfully, but these errors were encountered: