Avoid calling process.exit under node - #18754
Merged
Merged
Conversation
sbc100
force-pushed
the
logExceptionOnExit_node
branch
from
February 15, 2023 06:22
383d41e to
a7afed9
Compare
tlively
approved these changes
Feb 15, 2023
sbc100
force-pushed
the
logExceptionOnExit_node
branch
3 times, most recently
from
February 15, 2023 18:16
69ff9f1 to
a587987
Compare
sbc100
added a commit
that referenced
this pull request
Feb 15, 2023
This could help with some of the flaky thread tests we have been seeing as it means that we never try to process messages from already-terminated threads. Split out from #18754
sbc100
added a commit
that referenced
this pull request
Feb 15, 2023
This could help with some of the flaky thread tests we have been seeing as it means that we never try to process messages from already-terminated threads. Split out from #18754
sbc100
added a commit
that referenced
this pull request
Feb 15, 2023
This could help with some of the flaky thread tests we have been seeing as it means that we never try to process messages from already-terminated threads. Split out from #18754
sbc100
added a commit
that referenced
this pull request
Feb 15, 2023
This could help with some of the flaky thread tests we have been seeing as it means that we never try to process messages from already-terminated threads. Split out from #18754
sbc100
added a commit
that referenced
this pull request
Feb 15, 2023
This could help with some of the flaky thread tests we have been seeing as it means that we never try to process messages from already-terminated threads. Split out from #18754
sbc100
added a commit
that referenced
this pull request
Feb 16, 2023
This could help with some of the flaky thread tests we have been seeing as it means that we never try to process messages from already-terminated threads. Split out from #18754
sbc100
added a commit
that referenced
this pull request
Feb 16, 2023
This could help with some of the flaky thread tests we have been seeing as it means that we never try to process messages from already-terminated threads. Split out from #18754
sbc100
force-pushed
the
logExceptionOnExit_node
branch
10 times, most recently
from
February 17, 2023 22:47
054d157 to
b1f1efe
Compare
Instead we always prefer to let exceptions bubble out and get handles by whatever handlers are installed. Doing this did exposed a few places where we were calling back into the runtime after it had exited. This was previously being masked by the fact that we were bringing down the entire node process. This means that when running tests under node we will now be a little more sensitive to use-after-exit bugs in our runtime and test code, but I would argue this is good thing. This also means we no longer need to define logExceptionOnExit under node, which is node code size saving.
sbc100
force-pushed
the
logExceptionOnExit_node
branch
from
February 18, 2023 21:04
b1f1efe to
a6d108a
Compare
sbc100
enabled auto-merge (squash)
February 18, 2023 21:14
sbc100
added a commit
that referenced
this pull request
Feb 23, 2023
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Aug 27, 2025
The `checkMailbox` callback can occur after the thread has terminated. In this case calling into native code can trigger the `makeAbortWrapper` wrapper that is put around each native function which then results in a "program has already aborted!" error being thrown. Once solution to this is to make sure that the function which are called do not have `makeAbortWrapper` applied to them. This was the technique I used in emscripten-core#18754, but the list of functions became stale when emscripten_proxy_execute_task_queue was removed in emscripten-core#18852. A better solution is to wrap to whole function in callUserCallback, which takes case of checking if the runtime is alive before calling into native code. Fixes: emscripten-core#20067
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Aug 27, 2025
The `checkMailbox` callback can occur after the thread has terminated. In this case calling into native code can trigger the `makeAbortWrapper` wrapper that is put around each native function which then results in a "program has already aborted!" error being thrown. Once solution to this is to make sure that the function which are called do not have `makeAbortWrapper` applied to them. This was the technique I used in emscripten-core#18754, but the list of functions became stale when emscripten_proxy_execute_task_queue was removed in emscripten-core#18852. A better solution is to wrap to whole function in callUserCallback, which takes case of checking if the runtime is alive before calling into native code. Fixes: emscripten-core#20067
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Aug 27, 2025
The `checkMailbox` callback can occur after the thread has terminated. In this case calling into native code can trigger the `makeAbortWrapper` wrapper that is put around each native function which then results in a "program has already aborted!" error being thrown. Once solution to this is to make sure that the function which are called do not have `makeAbortWrapper` applied to them. This was the technique I used in emscripten-core#18754, but the list of functions became stale when emscripten_proxy_execute_task_queue was removed in emscripten-core#18852. A better solution is to wrap to whole function in callUserCallback, which takes case of checking if the runtime is alive before calling into native code. Fixes: emscripten-core#20067
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Aug 27, 2025
The `checkMailbox` callback can occur after the thread has terminated. In this case calling into native code can trigger the `makeAbortWrapper` wrapper that is put around each native function which then results in a "program has already aborted!" error being thrown. Once solution to this is to make sure that the function which are called do not have `makeAbortWrapper` applied to them. This was the technique I used in emscripten-core#18754, but the list of functions became stale when emscripten_proxy_execute_task_queue was removed in emscripten-core#18852. A better solution is to wrap to whole function in callUserCallback, which takes case of checking if the runtime is alive before calling into native code. Fixes: emscripten-core#20067
sbc100
added a commit
to sbc100/emscripten
that referenced
this pull request
Aug 27, 2025
The `checkMailbox` callback can occur after the thread has terminated. In this case calling into native code can trigger the `makeAbortWrapper` wrapper that is put around each native function which then results in a "program has already aborted!" error being thrown. Once solution to this is to make sure that the function which are called do not have `makeAbortWrapper` applied to them. This was the technique I used in emscripten-core#18754, but the list of functions became stale when emscripten_proxy_execute_task_queue was removed in emscripten-core#18852. A better solution is to wrap to whole function in callUserCallback, which takes case of checking if the runtime is alive before calling into native code. Fixes: emscripten-core#20067
sbc100
added a commit
that referenced
this pull request
Aug 28, 2025
The `checkMailbox` callback can occur after the thread has terminated. In this case calling into native code can trigger the `makeAbortWrapper` wrapper that is put around each native function which then results in a "program has already aborted!" error being thrown. Once solution to this is to make sure that the function which are called do not have `makeAbortWrapper` applied to them. This was the technique I used in #18754, but the list of functions became stale when emscripten_proxy_execute_task_queue was removed in #18852. A better solution is to wrap to whole function in callUserCallback, which takes care of checking if the runtime is alive before calling into native code. Fixes: #20067
inolen
pushed a commit
to inolen/emscripten
that referenced
this pull request
Feb 13, 2026
The `checkMailbox` callback can occur after the thread has terminated. In this case calling into native code can trigger the `makeAbortWrapper` wrapper that is put around each native function which then results in a "program has already aborted!" error being thrown. Once solution to this is to make sure that the function which are called do not have `makeAbortWrapper` applied to them. This was the technique I used in emscripten-core#18754, but the list of functions became stale when emscripten_proxy_execute_task_queue was removed in emscripten-core#18852. A better solution is to wrap to whole function in callUserCallback, which takes care of checking if the runtime is alive before calling into native code. Fixes: emscripten-core#20067
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Instead we always prefer to let exceptions bubble out and get handled by whatever handlers are installed.
Doing this did expose a few places where we were calling back into the runtime after it had exited. This was previously being masked by the fact that we were bringing down the entire node process. This means that when running tests under node we will now be a little more sensitive to use-after-exit bugs in our runtime and test code, but I would argue this is good thing.
This also means we no longer need to define logExceptionOnExit under node, which is a code size saving.