[dev.fuzz] all: merge master into dev.fuzz

Change-Id: I5d8c8329ccc9d747bd81ade6b1cb7cb8ae2e94b2

1 files changed, 17 insertions, 35 deletions

diff --git a/src/time/internal_test.go b/src/time/internal_test.go
index 35ce69b228..ffe54e47c2 100644
--- a/src/time/internal_test.go
+++ b/src/time/internal_test.go
@@ -33,48 +33,30 @@ var DaysIn = daysIn
 
 func empty(arg interface{}, seq uintptr) {}
 
-// Test that a runtimeTimer with a duration so large it overflows
-// does not cause other timers to hang.
+// Test that a runtimeTimer with a period that would overflow when on
+// expiration does not throw or cause other timers to hang.
 //
 // This test has to be in internal_test.go since it fiddles with
 // unexported data structures.
-func CheckRuntimeTimerOverflow() {
-	// We manually create a runtimeTimer to bypass the overflow
-	// detection logic in NewTimer: we're testing the underlying
-	// runtime.addtimer function.
+func CheckRuntimeTimerPeriodOverflow() {
+	// We manually create a runtimeTimer with huge period, but that expires
+	// immediately. The public Timer interface would require waiting for
+	// the entire period before the first update.
 	r := &runtimeTimer{
-		when: runtimeNano() + (1<<63 - 1),
-		f:    empty,
-		arg:  nil,
+		when:   runtimeNano(),
+		period: 1<<63 - 1,
+		f:      empty,
+		arg:    nil,
 	}
 	startTimer(r)
+	defer stopTimer(r)
 
-	// Start a goroutine that should send on t.C right away.
-	t := NewTimer(1)
-
-	defer func() {
-		// Subsequent tests won't work correctly if we don't stop the
-		// overflow timer and kick the timer proc back into service.
-		//
-		// The timer proc is now sleeping and can only be awoken by
-		// adding a timer to the *beginning* of the heap. We can't
-		// wake it up by calling NewTimer since other tests may have
-		// left timers running that should have expired before ours.
-		// Instead we zero the overflow timer duration and start it
-		// once more.
-		stopTimer(r)
-		t.Stop()
-		resetTimer(r, 0)
-	}()
-
-	// If the test fails, we will hang here until the timeout in the
-	// testing package fires, which is 10 minutes. It would be nice to
-	// catch the problem sooner, but there is no reliable way to guarantee
-	// that timers are run without doing something involving the scheduler.
-	// Previous failed attempts have tried calling runtime.Gosched and
-	// runtime.GC, but neither is reliable. So we fall back to hope:
-	// We hope we don't hang here.
-	<-t.C
+	// If this test fails, we will either throw (when siftdownTimer detects
+	// bad when on update), or other timers will hang (if the timer in a
+	// heap is in a bad state). There is no reliable way to test this, but
+	// we wait on a short timer here as a smoke test (alternatively, timers
+	// in later tests may hang).
+	<-After(25 * Millisecond)
 }
 
 var (