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.

Sign up for GitHub

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

Jump to bottom

sync/atomic: TestNilDeref flaky failure on windows-386 with runtime fatal error [1.23 backport] #70475

Closed
gopherbot opened this issue Nov 20, 2024 · 2 comments
Closed

sync/atomic: TestNilDeref flaky failure on windows-386 with runtime fatal error [1.23 backport] #70475

gopherbot opened this issue Nov 20, 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
Go1.23.4

Comments

@gopherbot
Copy link
Contributor

@dmitshur requested issue #70288 to be considered for backport to the next 1.23 minor release.

@gopherbot Please consider this issue for backport. It appears to be a case of stack corruption during fault handling, and we're now seeing this failure on both 1.23 and 1.22 release branches (e.g., here and here). We need to either fix the root problem, or otherwise at minimum skip the flaky test.
@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Nov 20, 2024
@gopherbot gopherbot mentioned this issue Nov 20, 2024
Closed
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Nov 20, 2024
@gopherbot gopherbot added this to the Go1.23.4 milestone Nov 20, 2024
@GoVeronicaGo GoVeronicaGo added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Nov 27, 2024
@gopherbot
Copy link
Contributor Author

Change https://go.dev/cl/632196 mentions this issue: [release-branch.go1.23] runtime: reserve 4kB for system stack on windows-386

gopherbot pushed a commit that referenced this issue Nov 27, 2024
@rsc @gopherbot
[release-branch.go1.23] runtime: reserve 4kB for system stack on wind…
25f042d 
…ows-386

The failures in #70288 are consistent with and strongly imply
stack corruption during fault handling, and debug prints show
that the Go code run during fault handling is running about
300 bytes above the bottom of the goroutine stack.
That should be okay, but that implies the DLL code that called
Go's handler was running near the bottom of the stack too,
and maybe it called other deeper things before or after the
Go handler and smashed the stack that way.

stackSystem is already 4096 bytes on amd64;
making it match that on 386 makes the flaky failures go away.
It's a little unsatisfying not to be able to say exactly what is
overflowing the stack, but the circumstantial evidence is
very strong that it's Windows.

For #70288.
Fixes #70475.

Change-Id: Ife89385873d5e5062a71629dbfee40825edefa49
Reviewed-on: https://go-review.googlesource.com/c/go/+/627375
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 7eeb0a1)
Reviewed-on: https://go-review.googlesource.com/c/go/+/632196
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Veronica Silina <veronicasilina@google.com>
@gopherbot
Copy link
Contributor Author

Closed by merging CL 632196 (commit 25f042d) to release-branch.go1.23.

mpminardi pushed a commit to tailscale/go that referenced this issue Jan 28, 2025
@rsc @mpminardi
[release-branch.go1.23] runtime: reserve 4kB for system stack on wind…
db801b2 
…ows-386

The failures in golang#70288 are consistent with and strongly imply
stack corruption during fault handling, and debug prints show
that the Go code run during fault handling is running about
300 bytes above the bottom of the goroutine stack.
That should be okay, but that implies the DLL code that called
Go's handler was running near the bottom of the stack too,
and maybe it called other deeper things before or after the
Go handler and smashed the stack that way.

stackSystem is already 4096 bytes on amd64;
making it match that on 386 makes the flaky failures go away.
It's a little unsatisfying not to be able to say exactly what is
overflowing the stack, but the circumstantial evidence is
very strong that it's Windows.

For golang#70288.
Fixes golang#70475.

Change-Id: Ife89385873d5e5062a71629dbfee40825edefa49
Reviewed-on: https://go-review.googlesource.com/c/go/+/627375
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 7eeb0a1)
Reviewed-on: https://go-review.googlesource.com/c/go/+/632196
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Veronica Silina <veronicasilina@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Milestone
Go1.23.4
Development

No branches or pull requests
2 participants
@gopherbot @GoVeronicaGo