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: "fatal: morestack on g0" on amd64 after upgrade to Go 1.21, stale bounds [1.21 backport] #67297

Closed
prattmic opened this issue May 10, 2024 · 2 comments
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Milestone

Comments

@prattmic
Copy link
Member

I requested issue #62440 to be considered for backport to the next 1.21 minor release.

@gopherbot Please backport to 1.21 and 1.22. This bug causes random crashes on cgocallback.

@prattmic prattmic added the CherryPickCandidate Used during the release process for point releases label May 10, 2024
@prattmic prattmic added this to the Go1.21.11 milestone May 10, 2024
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label May 10, 2024
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/585337 mentions this issue: [release-branch.go1.21] runtime: always update stack bounds on cgocallback

@gopherbot gopherbot modified the milestones: Go1.21.11, Go1.21.12 Jun 4, 2024
@dr2chase dr2chase added the CherryPickApproved Used during the release process for point releases label Jun 20, 2024
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Jun 20, 2024
gopherbot pushed a commit that referenced this issue Jun 24, 2024
…lback

callbackUpdateSystemStack contains a fast path to exit early without
update if SP is already within the g0.stack bounds.

This is not safe, as a subsequent call may have new stack bounds that
only partially overlap the old stack bounds. In this case it is possible
to see an SP that is in the old stack bounds, but very close to the
bottom of the bounds due to the partial overlap. In that case we're very
likely to "run out" of space on the system stack.

We only need to do this on extra Ms, as normal Ms have precise bounds
defined when we allocated the stack.

TSAN annotations are added to x_cgo_getstackbounds because bounds is a
pointer into the Go stack. The stack can be reused when an old thread
exits and a new thread starts, but TSAN can't see the synchronization
there. This isn't a new case, but we are now calling more often.

For #62440.
Fixes #67297.

Cq-Include-Trybots: luci.golang.try:go1.21-linux-amd64-longtest
Change-Id: I5389050494987b7668d0b317fb92f85e61d798ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/584597
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 1ffc296)
Reviewed-on: https://go-review.googlesource.com/c/go/+/585337
@gopherbot
Copy link
Contributor

Closed by merging ac14d4d to release-branch.go1.21.

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.
3 participants