time: TestAfterStop flaky on solaris-amd64-oraclerel

[bcmills]

--- FAIL: TestAfterStop (0.47s)
    sleep_test.go:244: failed to stop event 0
FAIL
FAIL	time	5.886s

2019-11-12T05:35:33-99957b6/solaris-amd64-oraclerel
2019-10-11T18:07:53-24f9238/solaris-amd64-oraclerel

CC @ianlancetaylor @rorth

[ianlancetaylor]

Interesting that it failed twice in the same way, once with the old timer implementation and once with the new. The test starts a timer to run for 50 milliseconds and assumes that it will stop the timer before that time is up. I wonder if occasionally on Solaris the test program is suspended for long enough for the timer to fire?

[gopherbot]

Change https://golang.org/cl/207457 mentions this issue: time: only fail TestAfterStop if it fails five times in a row

[rorth]

Ian Lance Taylor <[email protected]> writes:

Interesting that it failed twice in the same way, once with the old timer implementation and once with the new. The test starts a timer to run for 50 milliseconds and assumes that it will stop the timer before that time is up. I wonder if occasionally on Solaris the test program is suspended for long enough for the timer to fire?

I've run some experiments myself, both on bare metal and in kernel zones and on (fully) loaded and idle systems, running go test -count=1 time 1000 times in a row. I've only managed to provoke the failure in kernel zones on that particular Opteron system, not e.g. on another kernel zone running the identical Solaris version on a (faster) Intel CPU. Strangely, the failures didn't happen when I added -run TestAfterStop. With your patch, those failures are gone as expected. However, a related one remains, occurring about 5 out of 1000 times:

…

--- FAIL: TestTicker (1.20s) tick_test.go:26: 10 100ms ticks took 1.200364758s, expected [800ms,1.2s]

[gopherbot]

Change https://golang.org/cl/207403 mentions this issue: time: deflake TestTicker