-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?) [1.14 backport] #37968
Labels
Milestone
Comments
gopherbot
added
the
CherryPickCandidate
Used during the release process for point releases
label
Mar 20, 2020
Approved. This is a critical issue without a workaround. |
cagedmantis
added
CherryPickApproved
Used during the release process for point releases
and removed
CherryPickCandidate
Used during the release process for point releases
labels
Mar 20, 2020
I checked in the fix for #37688 at Thanks for cherry-picking to go 1.14.2! |
Change https://golang.org/cl/225279 mentions this issue: |
Closed by merging f75a45c to release-branch.go1.14. |
gopherbot
pushed a commit
that referenced
this issue
Mar 24, 2020
…d to g0 defer list during panic newdefer() actually adds the new defer to the current g's defer chain. That happens even if we are on the system stack, in which case the g will be the g0 stack. For open-coded defers, we call newdefer() (only during panic processing) while on the system stack, so the new defer is unintentionally added to the g0._defer defer list. The code later correctly adds the defer to the user g's defer list. The g0._defer list is never used. However, that pointer on the g0._defer list can keep a defer struct alive that is intended to be garbage-collected (smaller defers use a defer pool, but larger-sized defer records are just GC'ed). freedefer() does not zero out pointers when it intends that a defer become garbage-collected. So, we can have the pointers in a defer that is held alive by g0._defer become invalid (in particular d.link). This is the cause of the bad pointer bug in this issue The fix is to change newdefer (only used in two places) to not add the new defer to the gp._defer list. We just do it after the call with the correct gp pointer. (As mentioned above, this code was already there after the newdefer in addOneOpenDeferFrame.) That ensures that defers will be correctly garbage-collected and eliminate the bad pointer. This fix definitely fixes the original repro. I added a test and tried hard to reproduce the bug (based on the original repro code), but awasn't actually able to cause the bug. However, the test is still an interesting mix of heap-allocated, stack-allocated, and open-coded defers. For #37688 Fixes #37968 Fixes #37688 Change-Id: I1a481b9d9e9b9ba4e8726ef718a1f4512a2d6faf Reviewed-on: https://go-review.googlesource.com/c/go/+/224581 Run-TryBot: Dan Scales <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Keith Randall <[email protected]> (cherry picked from commit 825ae71) Reviewed-on: https://go-review.googlesource.com/c/go/+/225279 Run-TryBot: Ian Lance Taylor <[email protected]> Reviewed-by: Dan Scales <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
@ianlancetaylor requested issue #37688 to be considered for backport to the next 1.14 minor release.
The text was updated successfully, but these errors were encountered: