-
Notifications
You must be signed in to change notification settings - Fork 30k
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
timers: fix arbitrary object clearImmediate errors #37824
Conversation
ea16354
to
f0f059f
Compare
Can you add regression tests for these? |
Done. I'm not 100% happy with the non-REPL test, as looking at the code even sending regular objects to clearImmediate looks like it has some side-effects which might corrupt some state, but it doesn't throw now. |
proc.on('exit', common.mustCall((code) => { | ||
assert.strictEqual(code, 0); | ||
})); | ||
proc.stdin.write('clearImmediate({});\n.exit\n'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is not really required, since it was just caused by the crash but it does not hurt either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue, I think, was a bit different (if by "the crash" you mean that NRE for this._idleNext). The REPL crash was caused because an undefined
async_id
was given to emitDestroy
, and this caused an error in emitDestroyScript
(as the check there only checks <= 0
and undefined is not <= 0
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a better fix would've been to actually change the code there (in async_hooks.js
) to check for hasHooks(kDestroy) && asyncId > 0
instead of an early return - but that's probably out of scope for this minor issue, and maybe a crash there is better than "swallowing" bad async_ids which might cover errors elsewhere.
Fix errors that are caused by invoking clearImmediate with arbitrary objects. fixes: nodejs#37806 PR-URL: nodejs#37824 Fixes: nodejs#37806 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
f444985
to
fcc934f
Compare
Landed in fcc934f |
Fix errors that are caused by invoking clearImmediate with arbitrary objects. fixes: #37806 PR-URL: #37824 Fixes: #37806 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Fix errors that are caused by invoking clearImmediate with arbitrary objects. fixes: #37806 PR-URL: #37824 Fixes: #37806 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Fix errors that are caused by invoking clearImmediate with arbitrary objects. fixes: #37806 PR-URL: #37824 Fixes: #37806 Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Fix errors that are caused by invoking clearImmediate with arbitrary objects. (e.g.
clearImmediate({})
)timers.js
fixes the REPL crash.internal/timers.js
fixes another error that gets thrown.Both of the above already exist in the
clearTimeout
path.Fixes: #37806