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.22 backport] #67298

Closed
prattmic opened this issue May 10, 2024 · 4 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.22 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.22.4 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/585935 mentions this issue: [release-branch.go1.22] runtime: always update stack bounds on cgocallback

@podtserkovskiy
Copy link
Contributor

Is there a chance to include this into Go1.22.5? The original change is already in master. This one has a timed-out test, a rerun should fix the error

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 #67298.

Cq-Include-Trybots: luci.golang.try:go1.22-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/+/585935
Run-TryBot: Joedian Reid <joedian@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
@gopherbot
Copy link
Contributor

Closed by merging 3560cf0 to release-branch.go1.22.

@podtserkovskiy
Copy link
Contributor

Thank you very much @joedian

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

4 participants