runtime/race: NoRaceMutexPureHappensBefore failures

[bcmills]

NoRaceMutexPureHappensBefore             FAILED+
[…]
Passed 347 of 348 tests (99.71%, 1+, 0-)
0 expected failures (0 has not fail)
--- FAIL: TestRace (8.48s)
FAIL
FAIL	runtime/race	22.915s

2019-11-19T19:14:25-8608733/windows-amd64-longtest
2019-11-07T20:34:27-4751db9/windows-amd64-race

CC @aclements

[bcmills]

2020-04-09T01:16:43-376472d/windows-amd64-race
2020-03-23T03:44:45-1250a32/windows-amd64-race
2020-02-05T18:27:48-702226f/windows-amd64-race
2020-01-06T17:40:38-562fabc/windows-amd64-race

CC @dvyukov @randall77

[dvyukov]

I think we should print the race report for "FAILED+". Or can anybody reproduce this to extract the report?

[bcmills]

CC @dfava

[bcmills]

A linux-amd64-race TryBot (CL 275297):
https://storage.googleapis.com/go-build-log/e6c8fe6a/linux-amd64-race_bec686e0.log

[dfava]

Most likely the detector is flagging a race when the second go func(){...} is scheduled to run before the first go func() {...}. Indeed, there is a race in this scheduling. One possibility is to bump up the wait time in time.After() until this intermittent failure goes away.

Do we have the output from the race detector?

[gopherbot]

Change https://golang.org/cl/291292 mentions this issue: testing/race: increase wait time that forces a particular scheduling

[bcmills]

Do we have the output from the race detector?

The log I linked is the only log I have. (If you want to modify TestRace to dump more information on failure, I think that would be an excellent improvement to the test!)

[bcmills]

@gopherbot, please backport to Go 1.16. This is a test-only fix, and the test can spuriously fail in TryBot and release-testing runs for other backports.