aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDmitry Vyukov <dvyukov@google.com>2016-01-27 19:22:28 +0100
committerRuss Cox <rsc@golang.org>2016-01-27 20:49:36 +0000
commit572f7660a774ebd8552408a6058b36cc90f6f563 (patch)
tree635b05ea9130f6ded5621a525a77bbd9eac5ecef
parentd326a9641994eccdac1c95901762af45ec801bf1 (diff)
downloadgo-572f7660a774ebd8552408a6058b36cc90f6f563.tar.gz
go-572f7660a774ebd8552408a6058b36cc90f6f563.zip
runtime/race: run tests with GOMAXPROCS=1
We set GOMAXPROCS=1 to prevent test flakiness. There are two sources of flakiness: 1. Some tests rely on particular execution order. If the order is different, race does not happen at all. 2. Ironically, ThreadSanitizer runtime contains a logical race condition that can lead to false negatives if racy accesses happen literally at the same time. Tests used to work reliably in the good old days of GOMAXPROCS=1. So let's set it for now. A more reliable solution is to explicitly annotate tests with required execution order by means of a special "invisible" synchronization primitive (that's what is done for C++ ThreadSanitizer tests). This is issue #14119. This reduces flakes on RaceAsFunc3 test from 60/3000 to 1/3000. Fixes #14086 Fixes #14079 Fixes #14035 Change-Id: Ibaec6b2b21e27b62563bffbb28473a854722cf41 Reviewed-on: https://go-review.googlesource.com/18968 Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-rw-r--r--src/runtime/race/output_test.go5
-rw-r--r--src/runtime/race/race_test.go15
2 files changed, 18 insertions, 2 deletions
diff --git a/src/runtime/race/output_test.go b/src/runtime/race/output_test.go
index a9f9f0fbd5..0c71a019dd 100644
--- a/src/runtime/race/output_test.go
+++ b/src/runtime/race/output_test.go
@@ -51,7 +51,10 @@ func TestOutput(t *testing.T) {
}
cmd.Env = append(cmd.Env, env)
}
- cmd.Env = append(cmd.Env, "GORACE="+test.gorace)
+ cmd.Env = append(cmd.Env,
+ "GOMAXPROCS=1", // see comment in race_test.go
+ "GORACE="+test.gorace,
+ )
got, _ := cmd.CombinedOutput()
if !regexp.MustCompile(test.re).MatchString(string(got)) {
t.Fatalf("failed test case %v, expect:\n%v\ngot:\n%s",
diff --git a/src/runtime/race/race_test.go b/src/runtime/race/race_test.go
index 6898e74900..748f33883b 100644
--- a/src/runtime/race/race_test.go
+++ b/src/runtime/race/race_test.go
@@ -155,7 +155,20 @@ func runTests() ([]byte, error) {
}
cmd.Env = append(cmd.Env, env)
}
- cmd.Env = append(cmd.Env, `GORACE=suppress_equal_stacks=0 suppress_equal_addresses=0 exitcode=0`)
+ // We set GOMAXPROCS=1 to prevent test flakiness.
+ // There are two sources of flakiness:
+ // 1. Some tests rely on particular execution order.
+ // If the order is different, race does not happen at all.
+ // 2. Ironically, ThreadSanitizer runtime contains a logical race condition
+ // that can lead to false negatives if racy accesses happen literally at the same time.
+ // Tests used to work reliably in the good old days of GOMAXPROCS=1.
+ // So let's set it for now. A more reliable solution is to explicitly annotate tests
+ // with required execution order by means of a special "invisible" synchronization primitive
+ // (that's what is done for C++ ThreadSanitizer tests). This is issue #14119.
+ cmd.Env = append(cmd.Env,
+ "GOMAXPROCS=1",
+ "GORACE=suppress_equal_stacks=0 suppress_equal_addresses=0 exitcode=0",
+ )
return cmd.CombinedOutput()
}