This stops the test from failing with a known failure mode, and
creates time to look into what the next steps should be, if any.

For #69840.
Fixes #70238.

Change-Id: I060903d256ed65c5dfcd70ae76eb361cab63186f
Reviewed-on: https://go-review.googlesource.com/c/go/+/625197
Auto-Submit: Dmitri Shuralyov <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
Reviewed-by: Eric Grosse <[email protected]>
(cherry picked from commit bea9b91)
Reviewed-on: https://go-review.googlesource.com/c/go/+/627416
Reviewed-by: Dmitri Shuralyov <[email protected]>
Commit-Queue: Ian Lance Taylor <[email protected]>
Auto-Submit: Ian Lance Taylor <[email protected]>

syscall.SyscallN is implemented by runtime.syscall_syscalln, which makes
sure that the variadic argument doesn't escape.

There is no need to worry about the lifetime of the elements of the
variadic argument, as the compiler will keep them live until the
function returns.

For #70197
Fixes #70201

Change-Id: I12991f0be12062eea68f2b103fa0a794c1b527eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/625297
Reviewed-by: Ian Lance Taylor <[email protected]>
Reviewed-by: Alex Brainman <[email protected]>
Reviewed-by: David Chase <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
(cherry picked from commit 7fff741)
Reviewed-on: https://go-review.googlesource.com/c/go/+/630215
Reviewed-by: Dmitri Shuralyov <[email protected]>
Reviewed-by: Quim Muntal <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
Auto-Submit: Ian Lance Taylor <[email protected]>

…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 #70474.

Change-Id: Ife89385873d5e5062a71629dbfee40825edefa49
Reviewed-on: https://go-review.googlesource.com/c/go/+/627375
Reviewed-by: Ian Lance Taylor <[email protected]>
Auto-Submit: Russ Cox <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
(cherry picked from commit 7eeb0a1)
Reviewed-on: https://go-review.googlesource.com/c/go/+/632197
Reviewed-by: Cherry Mui <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
Auto-Submit: Veronica Silina <[email protected]>

Change-Id: I5e9be77389bcb215c114013c169841cfbcaa9550
Reviewed-on: https://go-review.googlesource.com/c/go/+/633235
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
Reviewed-by: Veronica Silina <[email protected]>
Auto-Submit: Gopher Robot <[email protected]>
Reviewed-by: Michael Knyszek <[email protected]>