runtime: fix deadlock in TestCrashDumpsAllThreads

TestCrashDumpsAllThreads carefully sets the number of Ps to one
greater than the number of non-preemptible loops it starts so that the
main goroutine can continue to run (necessary because of #10958).
However, if GC starts, it can take over that one spare P and lock up
the system while waiting for the non-preemptible loops, causing the
test to eventually time out. This deadlock is easily reproducible if
you run the runtime test with GOGC=1.

Fix this by forcing GOGC=off when running this test.

Change-Id: Ifb22da5ce33f9a61700a326ea92fcf4b049721d1
Reviewed-on: https://go-review.googlesource.com/19516
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Author: aclements

src/runtime/crash_unix_test.go

@@ -14,6 +14,7 @@ import (
 	"os/exec"
 	"path/filepath"
 	"runtime"
+	"strings"
 	"syscall"
 	"testing"
 )
@@ -52,6 +53,18 @@ func TestCrashDumpsAllThreads(t *testing.T) {
 	cmd = exec.Command(filepath.Join(dir, "a.exe"))
 	cmd = testEnv(cmd)
 	cmd.Env = append(cmd.Env, "GOTRACEBACK=crash")
+
+	// Set GOGC=off. Because of golang.org/issue/10958, the tight
+	// loops in the test program are not preemptible. If GC kicks
+	// in, it may lock up and prevent main from saying it's ready.
+	newEnv := []string{}
+	for _, s := range cmd.Env {
+		if !strings.HasPrefix(s, "GOGC=") {
+			newEnv = append(newEnv, s)
+		}
+	}
+	cmd.Env = append(newEnv, "GOGC=off")
+
 	var outbuf bytes.Buffer
 	cmd.Stdout = &outbuf
 	cmd.Stderr = &outbuf