Currently, the following compiler warning is generated by clang:
../src/node_process_methods.cc:71:3:
warning: indirection of non-volatile null pointer will be deleted,
not trap [-Wnull-dereference]
*static_cast<volatile void**>(nullptr) = nullptr;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/node_process_methods.cc:71:3: note:
consider using __builtin_trap() or qualifying pointer with 'volatile'
1 warning generated.
This commit adds the volatile qualifier to avoid this warning.
PR-URL: https://github.com/nodejs/node/pull/28261
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
The C++ land `node::FatalException()` is not in fact fatal anymore.
It gives the user a chance to handle the uncaught exception
globally by listening to the `uncaughtException` event. This patch
renames it to `TriggerUncaughtException` in C++ to avoid the confusion.
In addition rename the JS land handler to `onGlobalUncaughtException`
to reflect its purpose - we have to keep the alias
`process._fatalException` and use that for now since it has been
monkey-patchable in the user land.
This patch also
- Adds more comments to the global uncaught exception handling routine
- Puts a few other C++ error handling functions into the `errors`
namespace
- Moves error-handling-related bindings to the `errors` binding.
Refs: https://github.com/nodejs/node/commit/2b252acea47af3ebeac3d7e68277f015667264cc
PR-URL: https://github.com/nodejs/node/pull/28257
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
When piping data into an SHA3 hash, EVP_DigestFinal_ex is called in
hash._flush, bypassing safeguards in the JavaScript layer. Calling
hash.digest causes EVP_DigestFinal_ex to be called again, resulting
in a segmentation fault in the SHA3 implementation of OpenSSL.
A relatively easy solution is to cache the result of calling
EVP_DigestFinal_ex until the Hash object is garbage collected.
PR-URL: https://github.com/nodejs/node/pull/28251
Fixes: https://github.com/nodejs/node/issues/28245
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Have clearer ownership relations between the `Http2Ping`,
`Http2Settings` and `Http2Session` objects.
Ping and Settings objects are now owned by the `Http2Session`
instance, and deleted along with it, so neither type of object
refers to the session after it is gone.
In the case of `Http2Ping`s, that deletion is slightly delayed,
so we explicitly reset its `session_` property.
Fixes: https://github.com/nodejs/node/issues/28088
PR-URL: https://github.com/nodejs/node/pull/28150
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
At the collaborator summit in Berlin, the behaviour of
`worker.terminate()` was discussed.
In particular, switching from a callback-based to a Promise-based API
was suggested. While investigating that possibility later, it was
discovered that `.terminate()` was unintentionally synchronous up
until now (including calling its callback synchronously).
Also, the topic of its stability has been brought up. I have performed
two manual reviews of the native codebase for compatibility with
`.terminate()`, and performed some manual fuzz testing with the test
suite. At this point, bugs with `.terminate()` should, in my opinion,
be treated like bugs in other Node.js features.
(It is possible to make Node.js crash with `.terminate()` by messing
with internals and/or built-in prototype objects, but that is already
the case without `.terminate()` as well.)
This commit:
- Makes `.terminate()` an asynchronous operation.
- Makes `.terminate()` return a `Promise`.
- Runtime-deprecates passing a callback.
- Removes a warning about its stability from the documentation.
- Eliminates an unnecessary extra function from the C++ code.
A possible alternative to returning a `Promise` would be to keep the
method synchronous and just drop the callback. Generally, providing
an asynchronous API does provide us with a bit more flexibility.
Refs: https://github.com/nodejs/summit/issues/141
PR-URL: https://github.com/nodejs/node/pull/28021
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently, when configuring --without-ssl the following compiler warning
is generated:
../src/node_worker.cc:192:10:
warning: unused variable 'inspector_started' [-Wunused-variable]
bool inspector_started = false;
^
1 warning generated.
This commit adds a macro guard to the variable to avoid the warning.
PR-URL: https://github.com/nodejs/node/pull/28198
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The report shows CPU consumption %, but without the number of CPU cores,
a consumer cannot tell if the percent (given across all cores) is
actually problematic. E.g., 100% on one CPU is a problem, but 100% on
four CPUs is not necessarily.
This change adds CPU information (similar to `os.cpus()`) to the report
output. Extra info besides the count is also provided as to avoid future
breaking changes in the eventuality that someone needs it; changing the
datatype of `header.cpus` would be breaking.
PR-URL: https://github.com/nodejs/node/pull/28188
Refs: https://github.com/nodejs/diagnostics/issues/307
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
We have a test that verifies that JS execution from the Buffer
finalizer is accepted, and that errors thrown are passed
down synchronously.
However, since the finalizer executes during GC, this is behaviour is
fundamentally invalid and, for good reasons, disallowed by the
JS engine. This leaves us with the options of either finding a way
to allow JS execution from the callback, or explicitly forbidding it on
the N-API side as well.
This commit implements the former option, since it is the more
backwards-compatible one, in the sense that the current situation
sometimes appears to work as well and we should not break that
behaviour if we don’t have to, but rather try to actually make it
work reliably.
Since GC timing is largely unobservable anyway, this commit moves
the callback into a `SetImmediate()`, as we do elsewhere in the code,
and a second pass callback is not an easily implemented option,
as the API is supposed to wrap around Node’s `Buffer` API.
In this case, exceptions are handled like other uncaught exceptions.
Two tests have to be adjusted to account for the timing difference.
This is unfortunate, but unavoidable if we want to conform to the
JS engine API contract and keep all tests.
Fixes: https://github.com/nodejs/node/issues/26754
PR-URL: https://github.com/nodejs/node/pull/28082
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
- Extend the aliased buffer for stats objects to contain
the entire time spec (seconds and nanoseconds) for the time
values instead of calculating the milliseconds in C++ and
lose precision there.
- Calculate the nanosecond-precision time values in JS and expose
them in BigInt Stats objects as `*timeNs`. The
millisecond-precision values are now calculated from the
nanosecond-precision values.
PR-URL: https://github.com/nodejs/node/pull/21387
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Refactor the C++ code for creating `MessagePort`s to skip calling the
constructor and instead directly instantiating the `InstanceTemplate`,
and always throw an error from the `MessagePort` constructor.
This aligns behaviour with the web, and creating single `MessagePort`s
does not make sense anyway.
PR-URL: https://github.com/nodejs/node/pull/28032
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
napi_define_class is tested by passing NULL to all parameters that are
pointers, one at a time. Moreover, two bugs were corrected. One was
utf8name and the second was the property descriptor pointer. These
pointers were assumed to be non-NULL and now we have NULL checks.
PR-URL: https://github.com/nodejs/node/pull/27945
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
- Split the initialization of the inspector and other diagnostics
into `Environment::InitializeInspector()` and
`Environment::InitializeDiagnostics()` - these need to be
reinitialized separately after snapshot deserialization.
- Do not store worker url alongside the inspector parent handle,
instead just get it from the handle.
- Rename `Worker::profiler_idle_notifier_started_` to
`Worker::start_profiler_idle_notifier_` because it stores
the state inherited from the parent env to use for initializing
itself.
PR-URL: https://github.com/nodejs/node/pull/27539
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Move creation of `env->as_callback_data()`, `env->primordials()`
and `env->process()` into `Environment::CreateProperties()` and
call it in the `Environment` constructor - this can be replaced with
deserialization when we snapshot the per-environment properties
after the instantiation of `Environment`.
PR-URL: https://github.com/nodejs/node/pull/27539
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Inline `ProcessCliArgs()` in the `Environment` constructor, and
emit the `Environment` creation trace events with the arguments
earlier. Remove the unused arguments passed to `CreateProcessObject()`
since these are now attached to process in `PatchProcessObject()`
during pre-execution instead.
PR-URL: https://github.com/nodejs/node/pull/27539
Reviewed-By: Anna Henningsen <anna@addaleax.net>
NodeRuntime domain was introduced to give inspector client way to
fetch captured information before Node process is gone. We need
similar capability for work.
With current protocol inspector client can force worker to wait
on start by passing waitForDebuggerOnStart flag to NodeWorker.enable
method. So client has some time to setup environment, e.g. start
profiler. At the same time there is no way to prevent worker from
being terminated. So we can start capturing profile but we can not
reliably get captured data back.
This PR implemented NodeRuntime.notifyWhenWaitingForDisconnect
method for worker. When NodeRuntime.waitingForDisconnect notification
is enabled, worker will wait for explicit NodeWorker.detach call.
With this PR worker tooling story is nicely aligned with main thread
tooling story. The only difference is that main thread by default is
waiting for disconnect but worker thread is not waiting.
Issue: https://github.com/nodejs/node/issues/27677
PR-URL: https://github.com/nodejs/node/pull/27706
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
PTHREAD_STACK_MIN is 2 KB with musl, which is too small to safely
receive signals. PTHREAD_STACK_MIN + MINSIGSTKSZ is 8 KB on arm64,
which is the musl architecture with the biggest MINSIGSTKSZ so let's
use that as a lower bound and let's quadruple it just in case.
PR-URL: https://github.com/nodejs/node/pull/27855
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Using `ArrayBufferViewContents` over
`Buffer::Data()`/`Buffer::Length()` or `SPREAD_BUFFER_ARG` has the
advantages of creating fewer individual variables to keep track off,
not being a “magic” macro that creates variables, reducing code size,
and being faster when receiving on-heap TypedArrays.
PR-URL: https://github.com/nodejs/node/pull/27920
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Track received data correctly. Specifically, for the buffer that
is used for receiving data, we previously would try to increment
the current memory usage by its length, and later decrement it
by that, but in the meantime the buffer had been turned over to V8
and its length reset to zero. This gave the impression that more and
more memory was consumed by the HTTP/2 session when it was in fact not.
Fixes: https://github.com/nodejs/node/issues/27416
Refs: https://github.com/nodejs/node/pull/26207
PR-URL: https://github.com/nodejs/node/pull/27914
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
legendecas