src: do not crash if ToggleAsyncHook fails during termination#34362
src: do not crash if ToggleAsyncHook fails during termination#34362addaleax wants to merge 2 commits intonodejs:masterfrom
Conversation
nodejs-github-bot
added
c++
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
addaleax
force-pushed
the
inspector-no-bail-on-termination
branch
from
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 |
|
|
||
| void Agent::ToggleAsyncHook(Isolate* isolate, | ||
| const Global<Function>& fn) { | ||
| if (!parent_env_->can_call_into_js()) return; |
There was a problem hiding this comment.
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.
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.
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.
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 👍
addaleax
added
author ready
|
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 <me@gus.host> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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 <me@gus.host> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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 <me@gus.host> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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 <me@gus.host> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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/node#34361. Fixes: nodejs/node#34361 PR-URL: nodejs/node#34362 Fixes: nodejs/node#27261 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
6 participants
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