runtime/race: deflake tests

[dvyukov]

See https://go-review.googlesource.com/#/c/18968 for context.
Race tests run with GOMAXPROCS=1, this makes them more or less reliable. But the ultimate 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). But that would require going over 350 tests.

[gopherbot]

CL https://golang.org/cl/18968 mentions this issue.

[rsc]

Ideally this would happen, but I think Dmitriy is the only one who can really do it.

[bradfitz]

#19604 was marked as a dup of this bug.

If these tests can't be made reliable, I think it's time to disable them. Or give them, say, 10 chances to succeed before reporting a failure.

Marking this as Go 1.9 to either fix them, disable them or make them try harder to pass.

[josharian]

Another instance of #19604: https://build.golang.org/log/72ead1aab99537284ab770f1babb89492441db0b

[odeke-em]

How's it going @dvyukov? Might you have any bandwidth for this bug? Thanks.

[dvyukov]

@odeke-em No, but you don't need to wait for me. We need something simple along the following lines:

--- a/src/runtime/race/testdata/mop_test.go
+++ b/src/runtime/race/testdata/mop_test.go
@@ -9,6 +9,7 @@ import (
        "crypto/sha1"
        "errors"
        "fmt"
+       "internal/race"
        "io"
        "os"
        "runtime"
@@ -62,11 +63,18 @@ func TestRaceIntRWClosures(t *testing.T) {
        var x, y int
        ch := make(chan int, 2)
 
+       nosync := make(chan bool)
        go func() {
                y = x
+               race.Disable()
+               nosync <- true
+               race.Enable()
                ch <- 1
        }()
        go func() {
+               race.Disable()
+               <-nosync
+               race.Enable()
                x = 1
                ch <- 1
        }()

However, I wasn't able to reproduce any flakes on tip. I've tried:

go test -c -race runtime/race/testdata/mop_test.go
stress -failure="PASS" ./race.test -test.run TestRaceIntRWClosures

With different values of -p and also some additional goroutines/computations in the test to defeat 'runnext`.

[gopherbot]

Change https://golang.org/cl/267998 mentions this issue: runtime/race: remove race from TestNoRaceAfterFunc2

[mpx]

I was just looking into cleaning this up, and AFAICT, TestNoRaceAfterFunc2 is legitimately racey.

The test was added in 908e1b5. I suspect _ = x should be moved before AfterFunc or the test should be removed, but perhaps the original intent was something else?

In practice, the timer function may execute just after the function returns (racing with timer.Stop), or at least, that's when the race is reported:

=== RUN   TestNoRaceAfterFunc2
--- PASS: TestNoRaceAfterFunc2 (0.00s)
=== RUN   TestNoRaceAfterFunc3
==================
WARNING: DATA RACE
Write at 0x00c0000fae60 by goroutine 21:
  command-line-arguments_test.TestNoRaceAfterFunc2.func1()
      .../src/runtime/race/testdata/sync_test.go:130 +0x46
      
Previous read at 0x00c0000fae60 by goroutine 18:
  command-line-arguments_test.TestNoRaceAfterFunc2()
      .../src/runtime/race/testdata/sync_test.go:133 +0x12e
  testing.tRunner()
      .../src/testing/testing.go:1173 +0x202
      
Goroutine 21 (running) created at:
  time.goFunc()
      .../src/time/sleep.go:167 +0x51
      
Goroutine 18 (finished) created at:
  testing.(*T).Run()
      .../src/testing/testing.go:1218 +0x5c7
  testing.runTests.func1()
      .../src/testing/testing.go:1491 +0xa6
  testing.tRunner()
      .../src/testing/testing.go:1173 +0x202
  testing.runTests()
      .../src/testing/testing.go:1489 +0x624
  testing.(*M).Run()
      .../src/testing/testing.go:1397 +0x3b3
  main.main()
      _testmain.go:741 +0x236