]> Cypherpunks repositories - gostls13.git/commit
[release-branch.go1.22] 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:30 +0000 (19:14 +0000)
commit6d7a95abcac5192f539c34ea96b3b3de6b933b87
tree9dbfab3363099d125acdd31ee92f96bc38ac942c
parent6f05fa7a4f632fee7fadada8d31cf8755c709610
[release-branch.go1.22] 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 #70474.

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/+/632197
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