This repository has been archived by the owner on Apr 22, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 7.3k
setTimeout causing full cpu usage with non-integer durations #8065
Labels
Comments
sammyt
added a commit
to sammyt/node-coap
that referenced
this issue
Aug 3, 2014
avoiding issue nodejs/node-v0.x-archive#8065
Confirm overhead. Likely, (1) v8 is forced to use double instead int or (2) conversion double->int occurs at the junction of native and js. In any case, DOM-version of timers discard fractional part. I think, node's version must do so too. |
@sammyt Thank you for reporting this issue, I'm looking into this right now. |
misterdjules
pushed a commit
to misterdjules/node
that referenced
this issue
Aug 4, 2014
When backporting f8193ab into v0.10, a regression was introduced. Timers with non-integer timeout could trigger a infinite recursion with 100% cpu usage. This commit backports 93b0624 which fixes the regression. After backporting f8193ab, instead of using Date.now(), timers would use Timer.now() to determine if they had expired. However, Timer.now() is based on loop->time, which is not updated when a timer's remaining time is > 0 and < 1. With this commit, Timer.now() updates loop->time itself.
misterdjules
pushed a commit
to misterdjules/node
that referenced
this issue
Aug 4, 2014
When backporting f8193ab into v0.10, a regression was introduced. Timers with non-integer timeout could trigger a infinite recursion with 100% cpu usage. This commit backports 93b0624 which fixes the regression. After backporting f8193ab, instead of using Date.now(), timers would use Timer.now() to determine if they had expired. However, Timer.now() is based on loop->time, which is not updated when a timer's remaining time is > 0 and < 1. Timers would thus never timeout if their remaining time was at some point > 0 and < 1. With this commit, Timer.now() updates loop->time itself, and timers always timeout eventually. Fixes nodejs#8065 and nodejs#8068.
@misterdjules thanks for looking into it; just got our first support ticket regarding this + 0.10.30 at Heroku. |
arunoda
referenced
this issue
in meteor/meteor
Aug 14, 2014
mscdex
pushed a commit
to mscdex/node
that referenced
this issue
Dec 25, 2014
When backporting f8193ab into v0.10, a regression was introduced. Timers with non-integer timeout could trigger a infinite recursion with 100% cpu usage. This commit backports 93b0624 which fixes the regression. After backporting f8193ab, instead of using Date.now(), timers would use Timer.now() to determine if they had expired. However, Timer.now() is based on loop->time, which is not updated when a timer's remaining time is > 0 and < 1. Timers would thus never timeout if their remaining time was at some point > 0 and < 1. With this commit, Timer.now() updates loop->time itself, and timers always timeout eventually. Fixes nodejs#8065 and nodejs#8068.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have observed node locking up with full cpu utilization when using
setTimeout
with non-integer valuesThe follwing code snipit reliably reproduces the issue on my mac running node version v0.10.30
The
t
value was generated usingMath.random() * 1000
and any such value has the same effect for meThe following code however has no problems
I attached a debugger and the runtime appear to be stuck in a tight loop, here inside timers.js
UPDATE: fixed the working code (copy-paste fail)
The text was updated successfully, but these errors were encountered: