Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
gopherbot opened this issue Feb 25, 2013 · 10 comments

Comments

Projects
None yet
5 participants
@gopherbot
Copy link

commented Feb 25, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2013

Comment 1:

Definitely a bug. :/

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

Status changed to Accepted.

@adg

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2013

@adg

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2013

Comment 7:

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

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2013

Comment 8:

This issue was closed by revision 89cf67e.

Status changed to Fixed.

@adg

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2013

Comment 9:

Thanks Alec!
@gopherbot

This comment has been minimized.

Copy link
Author

commented Feb 25, 2013

Comment 10 by alec@swapoff.org:

No problem, thanks for fixing it so promptly!

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015

@rsc rsc removed the go1.1 label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 24, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.