unique: fatal error: found pointer to free object #69210
Comments
|
Do you have a test program to share? |
seankhliao
added
the
NeedsInvestigation
|
CC @mknyszek |
|
As @MikeMitchellWebDev states, a reproducer would be helpful. A few questions:
I've walked over the weak pointer implementation again for some possible reasons this could happen (like, accidentally having a preemption point while a pointer that shouldn't be visible is visible on the stack), but don't see anything there. I'll look at the At the very least, is it possible for you to share what types of things you're putting into Thanks for reporting. |
|
I believe it has to do with use in sync.Map. The unique.Handle inner type is a wrapper type of the form |
Got it, thanks. That aligns with the allocation size class (24 bytes). Together with the stack trace, that suggests that either one of these
Thanks, I'd appreciate a narrowed-down example. If it's happening only under load or memory pressure, try increasing That all being said, I think I have a lead on a weak pointer bug. Specifically, consider the following scenario:
The fix is straightforward. If the GC mark phase is active, then the weak-to-strong conversion needs to mark and scan the object whose strong pointer was just created. This can't happen outside the mark phase, because we're careful about making sure that, when we observe a weak pointer, it's always been swept already. So it's either definitely gone, or definitely still around. Even if this somehow isn't the problem, it's definitely a problem that can manifest as the issue you observed. I will send a patch. If you're able to, please give it a try. I can provide instructions. Thanks! |
|
I was able to create my own reproducer, once I had a suspicion of the problem. It might still be worthwhile trying out the patch, but https://go.dev/cl/610396 should fix it. Let me know if you need help applying it and building a custom Go toolchain. |
|
@gopherbot Please open a backport issue for Go 1.23. This problem causes rare crashes in the GC with no workaround when using the |
|
Backport issue(s) opened: #69240 (for 1.23). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
mknyszek
added
NeedsFix
|
Change https://go.dev/cl/610396 mentions this issue: |
|
It took me a while to find to de-Googlize and find the |
dmitshur
added
the
FixPending
|
Change https://go.dev/cl/610696 mentions this issue: |
…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 <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> (cherry picked from commit 79fd633) Reviewed-on: https://go-review.googlesource.com/c/go/+/610696 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
|
Completely fixed, thank you @mknyszek! |
Go version
go version go1.23.0 darwin/arm64
Output of
go envin your module/workspace:What did you do?
Using unique.Handle very heavily.
What did you see happen?
What did you expect to see?
No crash.
The text was updated successfully, but these errors were encountered: