Use the --unhandled-rejections=none CLI flag instead.
PR-URL: https://github.com/nodejs/node/pull/38210
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
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: https://github.com/nodejs/node/pull/29513
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Set the default maxBuffer size to 204,800 bytes for execSync,
execFileSync, and spawnSync.
APIs that return the child output as a string should have non-infinite
defaults for maxBuffer sizes to avoid out-of-memory error conditions. A
non-infinite default used to be the documented behaviour for all
relevant APIs, but the implemented behaviour for execSync, execFileSync
and spawnSync was to have no maxBuffer limits.
PR-URL: https://github.com/nodejs/node/pull/23027
Refs: https://github.com/nodejs/node/pull/22894
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Currently, when building with --debug
test-async-wrap-pop-id-during-load fails on macosx with the following
error:
$ out/Debug/node test/parallel/test-async-wrap-pop-id-during-load.js
assert.js:86
throw new AssertionError(obj);
^
AssertionError [ERR_ASSERTION]: EXIT CODE: 1, STDERR:
internal/bootstrap/loaders.js:275
const script = new ContextifyScript(
^
RangeError: Maximum call stack size exceeded
at NativeModule.compile (internal/bootstrap/loaders.js:275:22)
at NativeModule.require (internal/bootstrap/loaders.js:168:18)
at assert.js:31:43
at NativeModule.compile (internal/bootstrap/loaders.js:299:7)
at NativeModule.require (internal/bootstrap/loaders.js:168:18)
at internal/process/main_thread_only.js:23:16
at NativeModule.compile (internal/bootstrap/loaders.js:299:7)
at Function.NativeModule.require
(internal/bootstrap/loaders.js:168:18)
at startup (internal/bootstrap/node.js:58:38)
at bootstrapNodeJSCore (internal/bootstrap/node.js:878:3)
at Object.<anonymous>
(/node/test/parallel/test-async-wrap-pop-id-during-load.js:21:8)
at Module._compile (internal/modules/cjs/loader.js:707:30)
at Object.Module._extensions..js
(internal/modules/cjs/loader.js:718:10)
at Module.load (internal/modules/cjs/loader.js:605:32)
at tryModuleLoad (internal/modules/cjs/loader.js:544:12)
at Function.Module._load (internal/modules/cjs/loader.js:536:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:760:12)
at startup (internal/bootstrap/node.js:308:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:878:3)
This commit suggests increasing the stack_size to 80.
Refs: https://github.com/nodejs/node/pull/20940
PR-URL: https://github.com/nodejs/node/pull/23996
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This commit removes `common.crashOnUnhandledRejection()` and adds
`common.disableCrashOnUnhandledRejection()`.
To reduce the risk of mistakes and make writing tests that involve
promises simpler, always install the unhandledRejection hook in tests
and provide a way to disable it for the rare cases where it's needed.
PR-URL: https://github.com/nodejs/node/pull/21849
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
This makes sure there is enough stack space on different systems.
PR-URL: https://github.com/nodejs/node/pull/20940
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Improve AssertionError message in
test/parallel/test-async-wrap-pop-id-during-load.js to include the
contents of stderr when the spawned process fails.
Refs: https://github.com/nodejs/node/pull/20940/files#r190707951
PR-URL: https://github.com/nodejs/node/pull/20948
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/18018
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Weijia Wang <starkwang@126.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
If bootstrap throws and if ids are added to the async id stack and if
the exception wasn't handled by the fatal exception handler then the
AsyncCallbackScope destructor will cause the AsyncHooks::pop_ids() stack
check to fail. Causing the application to crash. So clear the async id
stack manually.
This is only possible if the user: 1) manually calls MakeCallback() or
2) uses async await in the top level. Which will cause _tickCallback()
to fire before bootstrap finishes executing.
The following example shows how the application can fail due to
exceeding the maximum call stack while using async await:
async function fn() {
fn();
throw new Error();
}
(async function() { await fn(); })();
If this occurs during bootstrap then the application will pring the
following warning a number of times then exit with a status of 0:
(node:*) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: *): Error
Here's the same recursive call done after enabling a new AsyncHook() the
following will print instead of the above warning and exit with a
non-zero code (currently it's 7 because of how node::FatalException
assigns error codes based on where the failure happened):
script.js:25
async function fn() {
^
RangeError: Maximum call stack size exceeded
at <anonymous>
at fn (script.js:25:18)
at fn (script.js:26:3)
....
This has to do with how Promises lazily enable PromiseHook if an
AsyncHook() is enabled. Whether these need to be made uniform is outside
the scope of this commit
Fixes: https://github.com/nodejs/node/issues/15448
PR-URL: https://github.com/nodejs/node/pull/15553
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
