-
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: do not crash if ToggleAsyncHook fails during termination #34362
Conversation
In the termination case, we should not crash. There’s also no harm being done by ignoring the termination exception here, since the thread is about to be torn down anyway. Also, add a guard against running this during shutdown. That is the likely cause of nodejs#34361. Fixes: nodejs#34361
5c2a7d0
to
643a109
Compare
CI: https://ci.nodejs.org/job/node-test-pull-request/32364/ (:green_heart:) |
Is there anyway to test this? (I guess this involves shutting down the instance in a particular way so that the inspector agent tries to call into JS when it's not supposed to but I am not sure how that can be triggered with even pummel) |
Yeah, apparently VS Code is able to trigger this but I’m not. If I had a reproduction, I’d add a test here… |
also /cc @nodejs/inspector |
@@ -841,13 +841,14 @@ void Agent::DisableAsyncHook() { | |||
|
|||
void Agent::ToggleAsyncHook(Isolate* isolate, | |||
const Global<Function>& fn) { | |||
if (!parent_env_->can_call_into_js()) return; |
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.
Would be better if some comments are added about when this would happen, maybe something like The inspector agent might attempt to toggle the inspector async hooks to stop tracking async call stacks when the Node.js instance is shutting down and is not supposed to execute JS anymore. To avoid crashing we'll just make it a noop and stop tracking async call stacks here
(I am assuming it's fine to just stop tracking because we probably don't care when the instance is shutting down?)
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.
Although to quote my comment in #27261 (comment) this still feels like a bug - we are doing inspector client cleanups after the client is being disconnected from the frontend. But I guess a fix like this wouldn't hurt and does the trick for most users which is what matters.
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.
On a side note I think an ultimate fix would be to correct the state management of either waiting_for_frontend_
, waiting_for_sessions_disconnect_
or waiting_for_resume_
, or add another one to the mix (though I have no idea how)
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’ve added a comment that explains that if we hit this condition, no async events are going to be emitted anyway, and added a link to your comment here 👍
CI: https://ci.nodejs.org/job/node-test-pull-request/32449/ (:green_heart:) |
Landed in 687dbd8 |
In the termination case, we should not crash. There’s also no harm being done by ignoring the termination exception here, since the thread is about to be torn down anyway. Also, add a guard against running this during shutdown. That is the likely cause of #34361. Fixes: #34361 PR-URL: #34362 Fixes: #27261 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: James M Snell <[email protected]>
In the termination case, we should not crash. There’s also no harm being done by ignoring the termination exception here, since the thread is about to be torn down anyway. Also, add a guard against running this during shutdown. That is the likely cause of #34361. Fixes: #34361 PR-URL: #34362 Fixes: #27261 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: James M Snell <[email protected]>
In the termination case, we should not crash. There’s also no harm being done by ignoring the termination exception here, since the thread is about to be torn down anyway. Also, add a guard against running this during shutdown. That is the likely cause of #34361. Fixes: #34361 PR-URL: #34362 Fixes: #27261 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: James M Snell <[email protected]>
In the termination case, we should not crash. There’s also no harm being done by ignoring the termination exception here, since the thread is about to be torn down anyway. Also, add a guard against running this during shutdown. That is the likely cause of #34361. Fixes: #34361 PR-URL: #34362 Fixes: #27261 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: James M Snell <[email protected]>
In the termination case, we should not crash. There’s also no harm
being done by ignoring the termination exception here, since the
thread is about to be torn down anyway.
Also, add a guard against running this during shutdown. That is the
likely cause of #34361.
Fixes: #34361
Fixes: #27261
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes