-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
[async_hooks] Wrong after callback in case of uncaughtException #22982
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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 <deb2001-github@yahoo.de> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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 <deb2001-github@yahoo.de> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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 <deb2001-github@yahoo.de> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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 <deb2001-github@yahoo.de> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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: