TestExec and TestExecHelper check for a workaround of a particular OS
bug on darwin that's triggered more often via asynchronous preemption.
As part of this, the test sets up 100 CPU-bound goroutines, and sets
GOMAXPROCS to 50, sleeping for a little bit before calling Exec. Thus
far, this is fine because the scheduler runs the Execing goroutine in a
timely manner. However, CL 309869 will reduce the minimum heap size,
causing a GC to happen during the test.
On a 16 CPU machine, with GOMAXPROCS at 50, and 100 CPU-bound
goroutines, both the OS scheduler and the Go scheduler are severly
oversaturated. As a result, the test often (not always, but often) runs
out for the full lifetime of those 100 goroutines, which run for about 1
second.
The minimum heap size reduction is not necessary to trigger this; an
additional call to runtime.GC in the helper is also sufficient to
trigger this delay.
The delay on its own isn't great, since it adds a whole second to
all.bash on its own. However, it also seems correlated with other
subprocess tests in the syscall package, namely TestPassFD and
TestFcntlFlock. These tests fail in a fairly superficial way: the file
descriptor for the temporary directories they make gets clobbered, is
closed, or becomes stale.
Change-Id: I213dd5e38967d19a8b317e6d4c5024b57f9e3fed
Reviewed-on: https://go-review.googlesource.com/c/go/+/360574
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
"os"
"os/exec"
"os/signal"
- "runtime"
"syscall"
"testing"
"time"
// We don't have to worry about restoring these values.
// We are in a child process that only runs this test,
// and we are going to call syscall.Exec anyhow.
- runtime.GOMAXPROCS(50)
os.Setenv("GO_WANT_HELPER_PROCESS", "3")
stop := time.Now().Add(time.Second)