Skip to content
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

runtime: goroutines that stop after calling runtime.RaceDisable break race detector [1.19 backport] #60948

Closed
gopherbot opened this issue Jun 22, 2023 · 3 comments
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Milestone

Comments

@gopherbot
Copy link

@mknyszek requested issue #60934 to be considered for backport to the next 1.19 minor release.

Thanks for the investigation and for sending a fix! That does look like a real problem to me.

I think this should probably be backported too, because although I imagine runtime.RaceDisable to be rare, this does cause some pretty serious false positives without any workaround.

@gopherbot please open backport issues for Go 1.20 and Go 1.19.

@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Jun 22, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jun 22, 2023
@gopherbot gopherbot added this to the Go1.19.11 milestone Jun 22, 2023
@gopherbot
Copy link
Author

Change https://go.dev/cl/505675 mentions this issue: [release-branch.go1.19] runtime: set raceignore to zero when starting a new goroutine

@cagedmantis
Copy link
Contributor

Approved as it is a serious issue without a workaround.

@cagedmantis cagedmantis added the CherryPickApproved Used during the release process for point releases label Jun 28, 2023
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Jun 28, 2023
@gopherbot
Copy link
Author

Closed by merging c4590af to release-branch.go1.19.

gopherbot pushed a commit that referenced this issue Jun 29, 2023
… a new goroutine

When reusing a g struct the runtime did not reset
g.raceignore. Initialize raceignore to zero when initially
setting racectx.

A goroutine can end with a non-zero raceignore if it exits
after calling runtime.RaceDisable without a matching
runtime.RaceEnable. If that goroutine's g is later reused
the race detector is in a weird state: the underlying
g.racectx is active, yet g.raceignore is non-zero, and
raceacquire/racerelease which check g.raceignore become
no-ops. This causes the race detector to report races when
there are none.

For #60934
Fixes #60948

Change-Id: Ib8e412f11badbaf69a480f03740da70891f4093f
Reviewed-on: https://go-review.googlesource.com/c/go/+/505055
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 48dbb62)
Reviewed-on: https://go-review.googlesource.com/c/go/+/505675
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Bypass: Carlos Amedee <carlos@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Development

No branches or pull requests

2 participants