This limits the throughput and resource consumption of the fuzz
workers in the tests, which also reduces the likelihood of running out
of address space in the fuzz coordinator during the test.
(Ideally the coordinator should not be limited by address space;
this just works around the failure mode in the tests for now.)
For #65434.
Change-Id: I3086c6278d6803a3dbf17a46ed01b68cedc92ad9
Cq-Include-Trybots: luci.golang.try:gotip-linux-386-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/560515
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
[short] skip
env GOCACHE=$WORK/cache
+# Warm up the build cache with GOMAXPROCS unrestricted.
+go test -c -o $devnull
+
+# For the fuzzing phase, we reduce GOMAXPROCS to avoid consuming too many
+# resources during the test. Ideally this would just free up resources to run
+# other parallel tests more quickly, but unfortunately it is actually necessary
+# in some 32-bit environments to prevent the fuzzing engine from running out of
+# address space (see https://go.dev/issue/65434).
+env GOMAXPROCS=2
+
# The fuzz function should be able to detect whether -timeout
# was set with T.Deadline. Note there is no F.Deadline, and
# there is no timeout while fuzzing, even if -fuzztime is set.
# There are no seed values, so 'go test' should finish quickly.
go test
+# For the fuzzing phase, we reduce GOMAXPROCS to avoid consuming too many
+# resources during the test. Ideally this would just free up resources to run
+# other parallel tests more quickly, but unfortunately it is actually necessary
+# in some 32-bit environments to prevent the fuzzing engine from running out of
+# address space (see https://go.dev/issue/65434).
+env GOMAXPROCS=2
+
# Fuzzing should exit 0 after fuzztime, even if timeout is short.
go test -timeout=3s -fuzz=FuzzFast -fuzztime=5s