-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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: fix unreliable assumption in js-native-api/test_cannot_run_js #51898
test: fix unreliable assumption in js-native-api/test_cannot_run_js #51898
Conversation
525308f
to
e3b6d32
Compare
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.
LGTM as a hotfix, but the test will basically become useless once V8 12.2 lands, as it will always return napi_ok
then.
Previously the test assumes that when the queued finalizer is run, it must be run at a point where env->can_call_into_js() is false (typically, during Environment shutdown), which is not certain. If GC kicks in early and the second pass finalizer is queued before the event loop runs the check callbacks, the finalizer would then be called in check callbacks (via native immediates), where the finalizer can still call into JS. Essentially, addons can't make assumptions about where the queued finalizer would be called. This patch updates the assertions in the test to account for that.
e3b6d32
to
4165dca
Compare
That's not certain, it really depends on what the heap looks like when the addon is loaded. Any subtle change to the internals can delay the GC to happen after the check callbacks are called in the event loop (or not happen at all), and then it'll be |
If this fixes the test, perhaps remove the flaky designation in Line 2 in f28ccd3
|
Updated the status file - was the designation even working in the first place? It still got caught in the CI it seems, and locally the test runner still reports it. (I think it should've been marked as PASS,CRASH instead?) |
Yes, it was working -- e.g. https://ci.nodejs.org/job/node-test-commit-ibmi/nodes=ibmi73-ppc64/1466/ (from #48180 (comment)) is yellow due to this test crashing and not red. |
It looks like the addon is failing to compile on Windows:
|
I tried this locally and can confirm the behavior. What fixed the compilation for me was this. @joyeecheung if you think it's good, feel free to apply it.
|
Landed in 30c9181 |
Previously the test assumes that when the queued finalizer is run, it must be run at a point where env->can_call_into_js() is false (typically, during Environment shutdown), which is not certain. If GC kicks in early and the second pass finalizer is queued before the event loop runs the check callbacks, the finalizer would then be called in check callbacks (via native immediates), where the finalizer can still call into JS. Essentially, addons can't make assumptions about where the queued finalizer would be called. This patch updates the assertions in the test to account for that. PR-URL: #51898 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Previously the test assumes that when the queued finalizer is run, it must be run at a point where env->can_call_into_js() is false (typically, during Environment shutdown), which is not certain. If GC kicks in early and the second pass finalizer is queued before the event loop runs the check callbacks, the finalizer would then be called in check callbacks (via native immediates), where the finalizer can still call into JS. Essentially, addons can't make assumptions about where the queued finalizer would be called. This patch updates the assertions in the test to account for that. PR-URL: #51898 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Previously the test assumes that when the queued finalizer is run, it must be run at a point where env->can_call_into_js() is false (typically, during Environment shutdown), which is not certain. If GC kicks in early and the second pass finalizer is queued before the event loop runs the check callbacks, the finalizer would then be called in check callbacks (via native immediates), where the finalizer can still call into JS. Essentially, addons can't make assumptions about where the queued finalizer would be called. This patch updates the assertions in the test to account for that. PR-URL: #51898 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Previously the test assumes that when the queued finalizer is run, it must be run at a point where env->can_call_into_js() is false (typically, during Environment shutdown), which is not certain. If GC kicks in early and the second pass finalizer is queued before the event loop runs the check callbacks, the finalizer would then be called in check callbacks (via native immediates), where the finalizer can still call into JS. Essentially, addons can't make assumptions about where the queued finalizer would be called. This patch updates the assertions in the test to account for that. PR-URL: nodejs#51898 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Previously the test assumes that when the queued finalizer is run, it must be run at a point where env->can_call_into_js() is false (typically, during Environment shutdown), which is not certain. If GC kicks in early and the second pass finalizer is queued before the event loop runs the check callbacks, the finalizer would then be called in check callbacks (via native immediates), where the finalizer can still call into JS. Essentially, addons can't make assumptions about where the queued finalizer would be called. This patch updates the assertions in the test to account for that. PR-URL: #51898 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Previously the test assumes that when the queued finalizer is run, it must be run at a point where env->can_call_into_js() is false (typically, during Environment shutdown), which is not certain. If GC kicks in early and the second pass finalizer is queued before the event loop runs the check callbacks, the finalizer would then be called in check callbacks (via native immediates), where the finalizer can still call into JS. Essentially, addons can't make assumptions about where the queued finalizer would be called. This patch updates the assertions in the test to account for that.