async_hooks,worker: fix process.exit() crashes in async fn with async_hook enabled #33347
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As the comment indicates, this fixes a DCHECK failure, although I don’t quite understand why it is happening in the first place.
Termination exceptions are similar to uncaught exceptions in that they should clear the async id stack, because no ongoing async callbacks will be brought to completion when execution terminates. Previously, there was a check that made sure that that happened when the termination occurred during the callback itself, but no such check was in place for the case that the termination occurred during microtasks started by them. This commit adds such a check, both for microtasks and the `nextTick` queue. The latter addition doesn’t fix a crash, but still makes sense conceptually. The condition here is also flipped from applying only on Worker threads to also applying on the main thread, and setting the `failed_` flag rather than reading it. The former makes sense because the public C++ `Stop(env)` API can have the same effect as worker thread termination, but on the main thread rather than a Worker thread.
Add regression tests for the case in which an async_hook is enabled inside a Worker thread and `process.exit()` is called during the async part of an async function. This commit includes multiple tests that seem like they should all crash in a similar way, but interestingly don’t. In particular, it’s surprising that the presence of a statement after `process.exit()` in a function has an effect on the kind of crash that’s being exhibited (V8 DCHECK vs. assertion in our own code) and the circumstances under which it crashes (e.g. the -1 and -2 tests can be “fixed” by reverting 13c5a16, although they should have the same behavior as the -3 and -4 tests).
nodejs-github-bot
added
c++
addaleax
added
the
async_hooks
|
CI: https://ci.nodejs.org/job/node-test-pull-request/31271/ (:yellow_heart:) |
cjihrig
approved these changes
May 11, 2020
jasnell
approved these changes
May 11, 2020
benjamingr
approved these changes
May 11, 2020
|
This is surprising, reading 13c5a16 I don't understand why it causes the test behavior change. (The changes themselves in this PR look fine although I also don't understand why CancelTerminateExecution is needed) |
…raction Co-authored-by: Colin Ihrig <cjihrig@gmail.com>
Me neither, really.
Yeah, me neither. I think the reason that V8 aborts here is that some |
addaleax
added
the
author ready
devnexen
approved these changes
May 11, 2020
addaleax
added a commit
that referenced
this pull request
May 15, 2020
As the comment indicates, this fixes a DCHECK failure, although I don’t quite understand why it is happening in the first place. PR-URL: #33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
addaleax
added a commit
that referenced
this pull request
May 15, 2020
Termination exceptions are similar to uncaught exceptions in that they should clear the async id stack, because no ongoing async callbacks will be brought to completion when execution terminates. Previously, there was a check that made sure that that happened when the termination occurred during the callback itself, but no such check was in place for the case that the termination occurred during microtasks started by them. This commit adds such a check, both for microtasks and the `nextTick` queue. The latter addition doesn’t fix a crash, but still makes sense conceptually. The condition here is also flipped from applying only on Worker threads to also applying on the main thread, and setting the `failed_` flag rather than reading it. The former makes sense because the public C++ `Stop(env)` API can have the same effect as worker thread termination, but on the main thread rather than a Worker thread. PR-URL: #33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
addaleax
added a commit
that referenced
this pull request
May 15, 2020
Add regression tests for the case in which an async_hook is enabled inside a Worker thread and `process.exit()` is called during the async part of an async function. This commit includes multiple tests that seem like they should all crash in a similar way, but interestingly don’t. In particular, it’s surprising that the presence of a statement after `process.exit()` in a function has an effect on the kind of crash that’s being exhibited (V8 DCHECK vs. assertion in our own code) and the circumstances under which it crashes (e.g. the -1 and -2 tests can be “fixed” by reverting 13c5a16, although they should have the same behavior as the -3 and -4 tests). PR-URL: #33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
|
Landed in c7eeef5...e65d189 |
codebytere
pushed a commit
that referenced
this pull request
May 16, 2020
As the comment indicates, this fixes a DCHECK failure, although I don’t quite understand why it is happening in the first place. PR-URL: #33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
codebytere
pushed a commit
that referenced
this pull request
May 16, 2020
Termination exceptions are similar to uncaught exceptions in that they should clear the async id stack, because no ongoing async callbacks will be brought to completion when execution terminates. Previously, there was a check that made sure that that happened when the termination occurred during the callback itself, but no such check was in place for the case that the termination occurred during microtasks started by them. This commit adds such a check, both for microtasks and the `nextTick` queue. The latter addition doesn’t fix a crash, but still makes sense conceptually. The condition here is also flipped from applying only on Worker threads to also applying on the main thread, and setting the `failed_` flag rather than reading it. The former makes sense because the public C++ `Stop(env)` API can have the same effect as worker thread termination, but on the main thread rather than a Worker thread. PR-URL: #33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
codebytere
pushed a commit
that referenced
this pull request
May 16, 2020
Add regression tests for the case in which an async_hook is enabled inside a Worker thread and `process.exit()` is called during the async part of an async function. This commit includes multiple tests that seem like they should all crash in a similar way, but interestingly don’t. In particular, it’s surprising that the presence of a statement after `process.exit()` in a function has an effect on the kind of crash that’s being exhibited (V8 DCHECK vs. assertion in our own code) and the circumstances under which it crashes (e.g. the -1 and -2 tests can be “fixed” by reverting 13c5a16, although they should have the same behavior as the -3 and -4 tests). PR-URL: #33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
Merged
codebytere
pushed a commit
that referenced
this pull request
Jun 7, 2020
As the comment indicates, this fixes a DCHECK failure, although I don’t quite understand why it is happening in the first place. PR-URL: #33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
codebytere
pushed a commit
that referenced
this pull request
Jun 7, 2020
Termination exceptions are similar to uncaught exceptions in that they should clear the async id stack, because no ongoing async callbacks will be brought to completion when execution terminates. Previously, there was a check that made sure that that happened when the termination occurred during the callback itself, but no such check was in place for the case that the termination occurred during microtasks started by them. This commit adds such a check, both for microtasks and the `nextTick` queue. The latter addition doesn’t fix a crash, but still makes sense conceptually. The condition here is also flipped from applying only on Worker threads to also applying on the main thread, and setting the `failed_` flag rather than reading it. The former makes sense because the public C++ `Stop(env)` API can have the same effect as worker thread termination, but on the main thread rather than a Worker thread. PR-URL: #33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
codebytere
pushed a commit
that referenced
this pull request
Jun 7, 2020
Add regression tests for the case in which an async_hook is enabled inside a Worker thread and `process.exit()` is called during the async part of an async function. This commit includes multiple tests that seem like they should all crash in a similar way, but interestingly don’t. In particular, it’s surprising that the presence of a statement after `process.exit()` in a function has an effect on the kind of crash that’s being exhibited (V8 DCHECK vs. assertion in our own code) and the circumstances under which it crashes (e.g. the -1 and -2 tests can be “fixed” by reverting 13c5a16, although they should have the same behavior as the -3 and -4 tests). PR-URL: #33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
codebytere
pushed a commit
that referenced
this pull request
Jun 9, 2020
As the comment indicates, this fixes a DCHECK failure, although I don’t quite understand why it is happening in the first place. PR-URL: #33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
codebytere
pushed a commit
to codebytere/node
that referenced
this pull request
Jun 9, 2020
Termination exceptions are similar to uncaught exceptions in that they should clear the async id stack, because no ongoing async callbacks will be brought to completion when execution terminates. Previously, there was a check that made sure that that happened when the termination occurred during the callback itself, but no such check was in place for the case that the termination occurred during microtasks started by them. This commit adds such a check, both for microtasks and the `nextTick` queue. The latter addition doesn’t fix a crash, but still makes sense conceptually. The condition here is also flipped from applying only on Worker threads to also applying on the main thread, and setting the `failed_` flag rather than reading it. The former makes sense because the public C++ `Stop(env)` API can have the same effect as worker thread termination, but on the main thread rather than a Worker thread. PR-URL: nodejs#33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
codebytere
pushed a commit
that referenced
this pull request
Jun 9, 2020
Add regression tests for the case in which an async_hook is enabled inside a Worker thread and `process.exit()` is called during the async part of an async function. This commit includes multiple tests that seem like they should all crash in a similar way, but interestingly don’t. In particular, it’s surprising that the presence of a statement after `process.exit()` in a function has an effect on the kind of crash that’s being exhibited (V8 DCHECK vs. assertion in our own code) and the circumstances under which it crashes (e.g. the -1 and -2 tests can be “fixed” by reverting 13c5a16, although they should have the same behavior as the -3 and -4 tests). PR-URL: #33347 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>
Merged
codebytere
added a commit
to electron/electron
that referenced
this pull request
Jun 18, 2020
codebytere
added a commit
to electron/electron
that referenced
this pull request
Jun 18, 2020
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
worker: call CancelTerminateExecution() before exiting Locker
As the comment indicates, this fixes a DCHECK failure, although I don’t
quite understand why it is happening in the first place.
async_hooks: clear async_id_stack for terminations in more places
Termination exceptions are similar to uncaught exceptions in that they
should clear the async id stack, because no ongoing async callbacks
will be brought to completion when execution terminates.
Previously, there was a check that made sure that that happened when
the termination occurred during the callback itself, but no such check
was in place for the case that the termination occurred during
microtasks started by them. This commit adds such a check, both for
microtasks and the
nextTickqueue. The latter addition doesn’t fixa crash, but still makes sense conceptually.
The condition here is also flipped from applying only on Worker threads
to also applying on the main thread, and setting the
failed_flagrather than reading it. The former makes sense because the public C++
Stop(env)API can have the same effect as worker thread termination,but on the main thread rather than a Worker thread.
test: regression tests for async_hooks + Promise + Worker interaction
Add regression tests for the case in which an async_hook is enabled
inside a Worker thread and
process.exit()is called during theasync part of an async function.
This commit includes multiple tests that seem like they should all
crash in a similar way, but interestingly don’t. In particular, it’s
surprising that the presence of a statement after
process.exit()in a function has an effect on the kind of crash that’s being
exhibited (V8 DCHECK vs. assertion in our own code) and the
circumstances under which it crashes (e.g. the -1 and -2 tests
can be “fixed” by reverting 13c5a16, although they
should have the same behavior as the -3 and -4 tests).
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes