]> Cypherpunks repositories - gostls13.git/commit
[release-branch.go1.23] runtime: reserve 4kB for system stack on windows-386
authorRuss Cox <rsc@golang.org>
Tue, 12 Nov 2024 22:23:12 +0000 (23:23 +0100)
committerGopher Robot <gobot@golang.org>
Wed, 27 Nov 2024 19:14:27 +0000 (19:14 +0000)
commit25f042daecda1058baa25b213f1692d22ff5fb73
treee3b4b9747c3a6545411ec2a780c3e92405c17e63
parentbe062b7f61486db3c93741e794bd51eda5cc6fce
[release-branch.go1.23] runtime: reserve 4kB for system stack on windows-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 7eeb0a188eb644486da9f77bae0375d91433d0bf)
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>
src/runtime/stack.go