cmd/go/internal/par: fix TestWorkParallel retries

When the test retried multiple times, it reused the same Work variable,
causing in the builders being flaky due to panics. I was able to
immediately reproduce the failure with stress and -race:

	$ go test -race -c && stress -p 32 ./par.test -test.run=TestWorkParallel$

	/tmp/go-stress909062277
	--- FAIL: TestWorkParallel (0.07s)
	panic: par.Work.Do: already called Do [recovered]
		panic: par.Work.Do: already called Do

Instead, use a new Work variable at each retry. Now, the line above
seems to never fail. Of course, much higher 'stress -p' values will
still result in "does not seem to be parallel" test failures since the
machine lacks resources. But those are test failures, not panics.

Fixes #26642.

Change-Id: I5e962eca7602cf413d911ff5669f56d4f52da5a7
Reviewed-on: https://go-review.googlesource.com/126355
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

diff --git a/src/cmd/go/internal/par/work_test.go b/src/cmd/go/internal/par/work_test.go
index 53a715ea81c73e6ecfbe4fc4f0455effd88a78c7..f104bc4106f208bc2fac5ce36955a971e5e9f064 100644 (file)
--- a/src/cmd/go/internal/par/work_test.go
+++ b/src/cmd/go/internal/par/work_test.go
@@ -32,9 +32,8 @@ func TestWork(t *testing.T) {
 }
 
 func TestWorkParallel(t *testing.T) {
-       var w Work
-
        for tries := 0; tries < 10; tries++ {
+               var w Work
                const N = 100
                for i := 0; i < N; i++ {
                        w.Add(i)