time: time.After(math.MaxInt64) kills all time.After() instances

[gopherbot]

by alec@swapoff.org:

Running this on go tip produces no output.

I realise putting MaxInt64 into time.After is not exactly expected usage, but it
happened and I thought I'd report it.

What steps will reproduce the problem?

http://play.golang.org/p/k2uA7Xo22u

What is the expected output?

I would expect the second goroutine to print a "." every second.

What do you see instead?

Nothing. Both selects block.

Which operating system are you using?

Darwin cavern.local 12.2.1 Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 PDT 2012;
root:xnu-2050.20.9~1/RELEASE_X86_64 x86_64

Which version are you using?  (run 'go version')

go version default darwin/amd64
33d3e7bbd3ef tip

Please provide any additional information below.

[adg]

Comment 1:

Definitely a bug. :/

Labels changed: added priority-soon, go1.1, packagebug, removed priority-triage, go1.1maybe.

Status changed to Accepted.

[adg]

Comment 2:

time.Duration(math.MaxInt64-n) still locks for small positive values of n.
time.Duration(math.MaxInt64 >> 1) appears to behave correctly.

[remyoudompheng]

Comment 3:

So it may be possible that preventing overflow in instances of "when := now() +
duration" (time/sleep.go) is enough to fix the issue.

[adg]

Comment 4:

When creating a timer, the duration is added to the current time in nanoseconds and
stored in an int64. This overflows for long durations, storing a negative "when" time.
In package runtime, the pending timers are stored in a queue that is sorted by "when".
The timerproc goroutine periodically checks this queue to see if any new events need to
be fired.
The way it checks is by iterating through the timers and computing 
  delta = t->when - now;
and stopping if delta >= 0.
If that loop exits with delta < 0, it's assumed that there's no work to do and the
goroutine is parked.
I think one important fix is to make timerproc use a separate flag to mean "didn't find
anything to do." instead of using a negative delta.
The other important fix is to prevent "when" from overflowing maxint64 in the first
place. I don't think Sleep and After should panic on overly large durations. Probably it
should just truncate when to maxint64 in those cases. I don't think this matters; nobody
will be sleeping in go programs past the year 2262. Or, if they are, our descendants can
revisit this a century before then.

[adg]

Comment 5:

https://golang.org/cl/7388056

[adg]

Comment 6:

On further examination, the runtime code looks fine. The CL above fixes the issue in the
time package.

Owner changed to @adg.

Status changed to Started.

[davecheney]

Comment 7:

@aat, thanks for figuring out how to reproduce this issue and reporting it.

[adg]

Comment 8:

This issue was closed by revision 89cf67e.

Status changed to Fixed.

[adg]

Comment 9:

Thanks Alec!

[gopherbot]

Comment 10 by alec@swapoff.org:

No problem, thanks for fixing it so promptly!