-
Notifications
You must be signed in to change notification settings - Fork 29.1k
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
[async_hooks] Wrong after callback in case of uncaughtException #22982
Comments
I think the issue might be that we manually kick off |
So, a few issues involved here:
|
For completeness the results with other node versions:
10.11.0 setTimeout:
8.12.0 setTimeout:
I think we should not signal I'm not sure about the 0/1 entries. If there are present because "something" / "the system" is running we should not remove them. But is there any need to have them on stack at all? Why not default to 0/1 if there is nothing on stack? |
The issue with |
Today, the global uncaught exception handler is the only place where asyncId 0 is not ignored and we still proceed to call emitAfter. This would've already failed one of our correctness tests in async_hooks if not for some other code meant to handle a different edge case. Fixes: nodejs#22982
Today, the global uncaught exception handler is the only place where asyncId 0 is not ignored and we still proceed to call emitAfter. This would've already failed one of our correctness tests in async_hooks if not for some other code meant to handle a different edge case. Fixes: nodejs#22982
Today, the global uncaught exception handler is the only place where asyncId 0 is not ignored and we still proceed to call emitAfter. This would've already failed one of our correctness tests in async_hooks if not for some other code meant to handle a different edge case. Fixes: #22982 PR-URL: #41424 Reviewed-By: Gerhard Stöbich <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]>
Today, the global uncaught exception handler is the only place where asyncId 0 is not ignored and we still proceed to call emitAfter. This would've already failed one of our correctness tests in async_hooks if not for some other code meant to handle a different edge case. Fixes: nodejs#22982 PR-URL: nodejs#41424 Reviewed-By: Gerhard Stöbich <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]>
Today, the global uncaught exception handler is the only place where asyncId 0 is not ignored and we still proceed to call emitAfter. This would've already failed one of our correctness tests in async_hooks if not for some other code meant to handle a different edge case. Fixes: #22982 PR-URL: #41424 Reviewed-By: Gerhard Stöbich <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]>
Today, the global uncaught exception handler is the only place where asyncId 0 is not ignored and we still proceed to call emitAfter. This would've already failed one of our correctness tests in async_hooks if not for some other code meant to handle a different edge case. Fixes: #22982 PR-URL: #41424 Reviewed-By: Gerhard Stöbich <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: James M Snell <[email protected]>
async_hooks call
after
with wrong id if an uncaughtException happens which does not end the process.Results in
if I change the sample above to use
setTimeout
insteadprocess.nextTick
the issue is limited to master and theasync_id
emitted is 0 instead 1.I tried to find the root cause and I thought it's in
_fatalException
which should emitafter
for all except the last ids and in case there are no hooks clear all except the last.But if I check the working
setTimeout
case in NodeJs 8.12.0 the stack only holds the async_ids for Timeout and TIMERWRAP but not the 0/1 entries.The text was updated successfully, but these errors were encountered: