-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
test: update test-timers-block-eventloop.js #16314
Conversation
@@ -11,7 +11,7 @@ const t2 = setInterval(() => { | |||
common.busyLoop(15); | |||
}, 10); | |||
|
|||
const t3 = setTimeout(common.mustNotCall('eventloop blocked!'), 100); | |||
const t3 = setTimeout(common.mustNotCall('eventloop blocked!'), 200); |
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.
Nit: it might make sense to use common.platformTimeout()
everywhere and keep the original values. Not sure if it is enough though.
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.
I'd also prefer common.platformTimeout()
if that works.
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.
I tested it with common.platformTimeout
just now. Behavior is the same with 100
. I will update the case with 200
and common.platformTimeout
togegher.
When CPU is busy, the above sequential case fails occasionally, expand the timeout value to fix it. Fixes: nodejs#16310
ea1d27c
to
41f1e25
Compare
common.busyLoop(12); | ||
}, 10); | ||
common.busyLoop(commonTimeout(12)); | ||
}, common.platformTimeout(10)); |
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.
For consistency, maybe use commonTimeout()
here too.
|
||
const t1 = setInterval(() => { | ||
common.busyLoop(12); | ||
}, 10); | ||
common.busyLoop(commonTimeout(12)); |
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.
I'm not sure we should use common.platformTimeout()
here. I think we don't want to increase the duration of the "busy" loop.
Edit: nvm this is probably correct or we will test something different from the original.
The stress tests did not reproduce the flakiness. Should we still merge this? Also this just showed up in a Windows CI, and I am fairly certain that I had seen this on other platforms in the past week when I took a stroll in the CI:
|
Probably stress wasn't rigorous enough. Seems like test is just too sensitive. I confirmed test after change fails 100% on pre-patched version. P.S. I've also seens this on https://ci.nodejs.org/job/node-test-binary-arm/11283/RUN_SUBSET=3,label=pi3-raspbian-jessie/console |
When CPU is busy, the above sequential case fails occasionally, expand the timeout value to fix it. PR-URL: nodejs#16314 Fixes: nodejs#16310 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
Landed in 83b8474 (nit fixed) |
When CPU is busy, the above sequential case fails occasionally, expand the timeout value to fix it. PR-URL: #16314 Fixes: #16310 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
When CPU is busy, the above sequential case fails occasionally, expand the timeout value to fix it. PR-URL: #16314 Fixes: #16310 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
When CPU is busy, the above sequential case fails occasionally, expand the timeout value to fix it. PR-URL: #16314 Fixes: #16310 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
When CPU is busy, the above sequential case fails occasionally, expand the timeout value to fix it. PR-URL: nodejs/node#16314 Fixes: nodejs/node#16310 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
When CPU is busy, the above sequential case fails occasionally, expand the timeout value to fix it. PR-URL: #16314 Fixes: #16310 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
When CPU is busy, the above sequential case fails occasionally, expand the timeout value to fix it. PR-URL: #16314 Fixes: #16310 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
When CPU is busy, the above sequential case fails occasionally, expand the timeout value to fix it. PR-URL: #16314 Fixes: #16310 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
When CPU is busy, the above sequential case fails occasionally, expand the timeout value to fix it. PR-URL: nodejs/node#16314 Fixes: nodejs/node#16310 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
When CPU is busy, the above sequential case fails occasionally,
expand the timeout value to fix it.
Fixes: #16310
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)