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

unique: fatal error: found pointer to free object [1.23 backport] #69240

Closed
gopherbot opened this issue Sep 4, 2024 · 2 comments
Closed

unique: fatal error: found pointer to free object [1.23 backport] #69240

gopherbot opened this issue Sep 4, 2024 · 2 comments
Labels
CherryPickApproved Used during the release process for point releases
Milestone

Comments

@gopherbot
Copy link
Contributor

@mknyszek requested issue #69210 to be considered for backport to the next 1.23 minor release.

@gopherbot Please open a backport issue for Go 1.23.

This problem causes rare crashes in the GC with no workaround when using the unique package, which was introduced in the Go 1.23 cycle.

@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Sep 4, 2024
@gopherbot gopherbot added this to the Go1.23.1 milestone Sep 4, 2024
@dmitshur dmitshur added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Sep 4, 2024
@gopherbot
Copy link
Contributor Author

Change https://go.dev/cl/610696 mentions this issue: [release-branch.go1.23] internal/weak: shade pointer in weak-to-strong conversion

@gopherbot gopherbot modified the milestones: Go1.23.1, Go1.23.2 Sep 5, 2024
gopherbot pushed a commit that referenced this issue Sep 6, 2024
…g conversion

There's a bug in the weak-to-strong conversion in that creating the
*only* strong pointer to some weakly-held object during the mark phase
may result in that object not being properly marked.

The exact mechanism for this is that the new strong pointer will always
point to a white object (because it was only weakly referenced up until
this point) and it can then be stored in a blackened stack, hiding it
from the garbage collector.

This "hide a white pointer in the stack" problem is pretty much exactly
what the Yuasa part of the hybrid write barrier is trying to catch, so
we need to do the same thing the write barrier would do: shade the
pointer.

Added a test and confirmed that it fails with high probability if the
pointer shading is missing.

For #69210.
Fixes #69240.

Change-Id: Iaae64ae95ea7e975c2f2c3d4d1960e74e1bd1c3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/610396
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
Reviewed-by: Michael Pratt <[email protected]>
Auto-Submit: Michael Knyszek <[email protected]>
(cherry picked from commit 79fd633)
Reviewed-on: https://go-review.googlesource.com/c/go/+/610696
Auto-Submit: Dmitri Shuralyov <[email protected]>
@gopherbot
Copy link
Contributor Author

Closed by merging CL 610696 (commit 82575f7) to release-branch.go1.23.

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
Projects
None yet
Development

No branches or pull requests

2 participants