-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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: print exceptions from PromiseRejectCallback #29513
Conversation
Previously, leaving the exception lying around would leave the JS engine in an invalid state, as it was not expecting exceptions to be thrown from the C++ `PromiseRejectCallback`, and lead to hard crashes under some conditions (e.g. with coverage enabled).
I am confused, when would our
I am not sure how/why Actual technical changes LGTM, I am not ✅ing simply because I did not checkout the code and reproduce what this fixed because I am not sure how to make it throw. |
@benjamingr If you look at test/parallel/test-ttywrap-stack.js, you’ll see that it generates unhandled rejections near the stack limit. In that case, the PromiseRejectCallback may also throw an exception, namely a stack depth exceeded exception, when it tries to run JS code. Currently, when running the test with (I’m not sure but it’s probably also possible to make the callback crash by overriding internals enough, e.g. |
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 for explaining how to test this Anna :]
Changes LGTM
Some minor JS lint errors to fix:
|
Thanks, CI should be fixed now – also updated another test to account for the changes here. |
Documenting here so people don't do futile "Resume Build" runs: At least some CI failures appear to be relevant edge cases. One example: test-digitalocean-ubuntu1604_sharedlibs_container-x64-10 13:09:28 not ok 1630 parallel/test-promise-reject-callback-exception
13:09:28 ---
13:09:28 duration_ms: 0.266
13:09:28 severity: fail
13:09:28 exitcode: 1
13:09:28 stack: |-
13:09:28 assert.js:373
13:09:28 throw err;
13:09:28 ^
13:09:28
13:09:28 AssertionError [ERR_ASSERTION]: stdout: <>
13:09:28 at Object.<anonymous> (/home/iojs/build/workspace/node-test-commit-linux-containered/test/parallel/test-promise-reject-callback-exception.js:23:3)
13:09:28 at Module._compile (internal/modules/cjs/loader.js:936:30)
13:09:28 at Object.Module._extensions..js (internal/modules/cjs/loader.js:947:10)
13:09:28 at Module.load (internal/modules/cjs/loader.js:789:32)
13:09:28 at Function.Module._load (internal/modules/cjs/loader.js:702:12)
13:09:28 at Function.Module.runMain (internal/modules/cjs/loader.js:999:10)
13:09:28 at internal/main/run_main_module.js:17:11 {
13:09:28 generatedMessage: false,
13:09:28 code: 'ERR_ASSERTION',
13:09:28 actual: false,
13:09:28 expected: true,
13:09:28 operator: '=='
13:09:28 }
13:09:28 ... |
Previously, leaving the exception lying around would leave the JS engine in an invalid state, as it was not expecting exceptions to be thrown from the C++ `PromiseRejectCallback`, and lead to hard crashes under some conditions (e.g. with coverage enabled). PR-URL: #29513 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Landed in e095e64. |
Previously, leaving the exception lying around would leave the JS engine in an invalid state, as it was not expecting exceptions to be thrown from the C++ `PromiseRejectCallback`, and lead to hard crashes under some conditions (e.g. with coverage enabled). PR-URL: #29513 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Previously, leaving the exception lying around would leave the JS engine in an invalid state, as it was not expecting exceptions to be thrown from the C++ `PromiseRejectCallback`, and lead to hard crashes under some conditions (e.g. with coverage enabled). PR-URL: #29513 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Just want to say thank you from 2020 😭 |
Previously, leaving the exception lying around would leave the JS
engine in an invalid state, as it was not expecting exceptions to
be thrown from the C++
PromiseRejectCallback
, and lead to hardcrashes under some conditions (e.g. with coverage enabled).
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes