-
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
src: fix cb scope bugs involved in termination #45596
Conversation
Any idea? :) |
test/parallel/test-worker-with-nested-async-stack-gets-terminated.js
Outdated
Show resolved
Hide resolved
@legendecas Could you run the CI for this? |
src/api/callback.cc
Outdated
auto perform_stopping_check = [&]() { | ||
if (env_->is_stopping()) { | ||
if (!env_->can_call_into_js()) { |
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 difference here between !env_->can_call_into_js()
and env_->is_stopping()
is trivial. Environment::can_call_into_js()
also checks if Environment::is_stopping_
is set. Maybe @addaleax can chime in here?
If this line is updated, the lambda variable should also be renamed as perform_call_js_check
or similar. Also, I'd find the checks if (!env_->can_call_into_js()) return;
below can be merged with this lambda call too.
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.
Yeah, semantically, this should be checking for whether we’re currently stopping the current environment through a termination exception, so is_stopping()
would seem to be the correct choice?
Any thoughts on this PR? |
Would you mind updating the PR according to addaleax's comment above? Thanks! |
@legendecas addaleax's suggestion does not fix the bug. Please see above for why. I suggest that remove Lines 637 to 639 in c203921
|
With #45907, |
Be more aggresive to clean up the async id stack, and ensure the cleanup when terminating. Calling SetIdle() when terminating is not harmless. When node terminates due to an unhandled exception, v8 preseves the vm state, which is JS and notifies node through PerIsolateMessageListener(). If node calls SetIdle() later, v8 complains because it requires the vm state to either be EXTERNEL or IDLE when embedder calling SetIdle().
53f19ce
to
af95ec8
Compare
@legendecas Got you. Changed, PTAL |
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.
Thanks!
A test crashed. I wonder if there is a way to get a full stacktrace 🤔️
|
According to the reliability report nodejs/reliability#503, the failed test doesn't seem to be introduced in this PR. I've resumed the build. |
@legendecas Could you merge this? |
Landed in 7a37829 |
Be more aggresive to clean up the async id stack, and ensure the cleanup when terminating. Calling SetIdle() when terminating is not harmless. When node terminates due to an unhandled exception, v8 preseves the vm state, which is JS and notifies node through PerIsolateMessageListener(). If node calls SetIdle() later, v8 complains because it requires the vm state to either be EXTERNEL or IDLE when embedder calling SetIdle(). PR-URL: #45596 Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Be more aggresive to clean up the async id stack, and ensure the cleanup when terminating. Calling SetIdle() when terminating is not harmless. When node terminates due to an unhandled exception, v8 preseves the vm state, which is JS and notifies node through PerIsolateMessageListener(). If node calls SetIdle() later, v8 complains because it requires the vm state to either be EXTERNEL or IDLE when embedder calling SetIdle(). PR-URL: #45596 Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Be more aggresive to clean up the async id stack, and ensure the cleanup when terminating. Calling SetIdle() when terminating is not harmless. When node terminates due to an unhandled exception, v8 preseves the vm state, which is JS and notifies node through PerIsolateMessageListener(). If node calls SetIdle() later, v8 complains because it requires the vm state to either be EXTERNEL or IDLE when embedder calling SetIdle(). PR-URL: #45596 Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
An inheritor of #45422 and a fix to #43084. I move the original failing test back to the test/parallel/ to increase the chance that it exercises the defect, at which this PR is targeted.
To see the bug in 43084, apply this patch and run the script