When no error occurs, use `null` instead of `undefined` for the `error`
argument of the `writable.write()` and `writable.end()` callbacks.
Fixes: https://github.com/nodejs/node/issues/44290
PR-URL: https://github.com/nodejs/node/pull/44312
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Minwoo Jung <nodecorelab@gmail.com>
The THROW_ERR_* functions interpret the first argument as a printf-like
format string, which is problematic when it contains unsanitized user
input. This typically happens when a printf-like function is used to
produce the error message, which is then passed to a THROW_ERR_*
function, which again interprets the error message as a format string.
Fix such occurrences by properly formatting error messages using static
format strings only, and in a single step.
PR-URL: https://github.com/nodejs/node/pull/44314
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Zeyu "Alex" Yang <himself65@outlook.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
md and mgf1_md are internal variable names and should not appear in
JS error messages. Also include the invalid digest name in the error
message.
PR-URL: https://github.com/nodejs/node/pull/44307
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Add WebPerf API `performance.setResourceTimingBufferSize` and event
`'resourcetimingbufferfull'` support.
The resource timing entries are added to the global performance
timeline buffer automatically when using fetch. If users are not
proactively cleaning these events, it can grow without limit. Apply
the https://www.w3.org/TR/timing-entrytypes-registry/ default
resource timing buffer max size so that the buffer can be limited
to not grow indefinitely.
PR-URL: https://github.com/nodejs/node/pull/44220
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/44271
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
It's difficult for V8 to handle Error.stackTraceLimit in the snapshot,
so delete it from the Error constructor if it's present before
snapshot serialization, and re-install it after deserialization.
In addition try not to touch it from our internals during snapshot
building in the first place by updating
isErrorStackTraceLimitWritable().
PR-URL: https://github.com/nodejs/node/pull/44203
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
parallel/test-http-server-request-timeouts-mixed.js test was sometimes
failing due to insufficient tolerance between the connection timeout
checking interval, and the expected timeout specified in the test.
This change makes the checking interval more frequent, and decouples
the timeout for the check from the checking interval.
PR-URL: https://github.com/nodejs/node/pull/44169
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
To comply with RFC 7301, make TLS servers send a fatal alert during the
TLS handshake if both the client and the server are configured to use
ALPN and if the server does not support any of the protocols advertised
by the client.
This affects HTTP/2 servers. Until now, applications could intercept the
'unknownProtocol' event when the client either did not advertise any
protocols or if the list of protocols advertised by the client did not
include HTTP/2 (or HTTP/1.1 if allowHTTP1 was true). With this change,
only the first case can be handled, and the 'unknownProtocol' event will
not be emitted in the second case because the TLS handshake fails and no
secure connection is established.
PR-URL: https://github.com/nodejs/node/pull/44031
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This patch stores the metadata about the Node.js binary
into the SnapshotData and adds fields denoting how the
snapshot was generated, on what platform it was
generated as well as the V8 cached data version flag.
Instead of simply crashing when the metadata doesn't
match, Node.js now prints an error message and exit with
1 for the customized snapshot, or ignore the snapshot
and start from scratch if it's the default one.
PR-URL: https://github.com/nodejs/node/pull/44132
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
The term "native module" dates back to some of the oldest code
in the code base. Within the context of Node.js core it usually
refers to modules that are native to Node.js (e.g. fs, http),
but it can cause confusion for people who don't work on this
part of the code base, as "native module" can also refer to
native addons - which is even the case in some of the API
docs and error messages.
This patch tries to make the usage of these terms more consistent.
Now within the context of Node.js core:
- JavaScript scripts that are built-in to Node.js are now referred
to as "built-in(s)". If they are available as modules,
they can also be referred to as "built-in module(s)".
- Dynamically-linked shared objects that are loaded into
the Node.js processes are referred to as "addons".
We will try to avoid using the term "native modules" because it could
be ambiguous.
Changes in this patch:
File names:
- node_native_module.h -> node_builtins.h,
- node_native_module.cc -> node_builtins.cc
C++ binding names:
- `native_module` -> `builtins`
`node::Environment`:
- `native_modules_without_cache` -> `builtins_without_cache`
- `native_modules_with_cache` -> `builtins_with_cache`
- `native_modules_in_snapshot` -> `builtins_in_cache`
- `native_module_require` -> `builtin_module_require`
`node::EnvSerializeInfo`:
- `native_modules` -> `builtins
`node::native_module::NativeModuleLoader`:
- `native_module` namespace -> `builtins` namespace
- `NativeModuleLoader` -> `BuiltinLoader`
- `NativeModuleRecordMap` -> `BuiltinSourceMap`
- `NativeModuleCacheMap` -> `BuiltinCodeCacheMap`
- `ModuleIds` -> `BuiltinIds`
- `ModuleCategories` -> `BuiltinCategories`
- `LoadBuiltinModuleSource` -> `LoadBuiltinSource`
`loader.js`:
- `NativeModule` -> `BuiltinModule` (the `NativeModule` name used in
`process.moduleLoadList` is kept for compatibility)
And other clarifications in the documentation and comments.
PR-URL: https://github.com/nodejs/node/pull/44135
Fixes: https://github.com/nodejs/node/issues/44036
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Jan Krems <jan.krems@gmail.com>
These tests spawn many workers, which may be CPU intensive causing
timeouts (see the referenced PR for more details). Let's move them
to sequential.
Refs: https://github.com/nodejs/node/pull/44090
PR-URL: https://github.com/nodejs/node/pull/44139
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
This test uses the deprecated methods in `diagnostic_channel` (see the
reference), which are deprecated because the channels can be GC'd while
in use, leading to lost messages.
Change to use the non-deprecated APIs, which should work. I wasn't able
to reproduce this locally; I assume it's memory dependent.
Refs: https://github.com/nodejs/node/pull/42714
Fixes: https://github.com/nodejs/node/issues/44143
PR-URL: https://github.com/nodejs/node/pull/44144
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Modern s390x x15 has accelerated zlib operations on the CPU. Many
distros currently have patches to take advantage of this feature. One
side-effect of these patches is that compression routine is no longer
deterministic as with software. Interruption to input produces
different compressed results. Invalid input can result in processor
fault.
PR-URL: https://github.com/nodejs/node/pull/44117
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
These tests seem to timeout quite often. I don't know why, but one
possible reason is that they are starting a lot of threads. It seems
that tests in `test/parallel` are assumed to only start one thread each,
so having 11 threads running at a time feels like a lot.
It also seems that these tests fail in a correlated fashion: take a look
at [this reliability report][]. The failures all occur on the same build
machines on the same PRs. This suggests to me some sort of CPU
contention.
[this reliability report]: https://github.com/nodejs/reliability/issues/334
On my Linux machine decreasing the parallelism & iterations here reduce
the `user` time from ~11.5 seconds to ~2 seconds, depending on the test.
I have seen these tests take 30-60 seconds on CI (Alpine in particular).
I went back to the diffs that introduced that introduced these changes
and verified that they failed at least 90% of the time with the reduced
iteration count, which feels sufficient.
Refs: https://github.com/nodejs/node/issues/43499
Refs: https://github.com/nodejs/node/issues/43084
PR-URL: https://github.com/nodejs/node/pull/44090
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Ensures that mutating the `Object` prototype does not influence the
parsing of `package.json` files.
PR-URL: https://github.com/nodejs/node/pull/44007
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
This patch:
- Make NativeModuleLoader::LookupAndCompile() detect parameters based
on module IDs. This allows us to compile more builtins when
generating the embedded bootstrap, including
- internal/per_context/*
- internal/bootstrap/*
- internal/main/*
- Move pre_execution.js to lib/internal/process as it needs to be
compiled as a regular built-in module, unlike other scripts
in lib/internal/bootstrap
- Move markBootstrapComplete() to the performance binding instead of
making it a function-wrapper-based global to reduce number of
special cases.
PR-URL: https://github.com/nodejs/node/pull/44018
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Co-authored-by: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/44048
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
As a consequence of https://github.com/nodejs/node/issues/43014 ,
server sockets and others, once connected, report string family
names. But when feeding these to Socket.connect(), it passes
these to host resolution with a string for family while a numeric
family is expected internally. This results in wrong hints flags
to be set and resolution to fail.
As solution, is to add ability to handle both numeric and string
family names when doing lookup and connect.
Fixes: https://github.com/nodejs/node/issues/44003
PR-URL: https://github.com/nodejs/node/pull/44083
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This patch introduces `--build-snapshot` and `--snapshot-blob` options
for creating and using user land snapshots.
For the initial iteration, user land CJS modules and ESM are not yet
supported in the snapshot, so only one single file can be snapshotted
(users can bundle their applications into a single script with their
bundler of choice to build a snapshot though).
A subset of builtins should already work, and support for more builtins
are being added. This PR includes tests checking that the TypeScript
compiler and the marked markdown renderer (and the builtins they use)
can be snapshotted and deserialized.
To generate a snapshot using `snapshot.js` as entry point and write the
snapshot blob to `snapshot.blob`:
```
$ echo "globalThis.foo = 'I am from the snapshot'" > snapshot.js
$ node --snapshot-blob snapshot.blob --build-snapshot snapshot.js
```
To restore application state from `snapshot.blob`, with `index.js` as
the entry point script for the deserialized application:
```
$ echo "console.log(globalThis.foo)" > index.js
$ node --snapshot-blob snapshot.blob index.js
I am from the snapshot
```
Users can also use the `v8.startupSnapshot` API to specify an entry
point at snapshot building time, thus avoiding the need of an additional
entry script at deserialization time:
```
$ echo "require('v8').startupSnapshot.setDeserializeMainFunction(() => console.log('I am from the snapshot'))" > snapshot.js
$ node --snapshot-blob snapshot.blob --build-snapshot snapshot.js
$ node --snapshot-blob snapshot.blob
I am from the snapshot
```
Note that this patch only adds functionality to the `node` executable
for building run-time user-land snapshots, the generated snapshot is
stored into a separate file on disk. Building a single binary with both
Node.js and an embedded snapshot has already been possible with the
`--node-snapshot-main` option to the `configure` script if the user
compiles Node.js from source. It would be a different task to enable the
`node` executable to produce a single binary that contains both Node.js
and an embedded snapshot without building Node.js from source, which
should be layered on top of the SEA (Single Executable Apps) initiative.
Known limitations/bugs that are being fixed in the upstream:
- V8 hits a DCHECK when deserializing certain mutated globals, e.g.
`Error.stackTraceLimit` (it should work fine in the release build,
however): https://chromium-review.googlesource.com/c/v8/v8/+/3319481
- Layout of V8's read-only heap can be inconsistent after
deserialization, resulting in memory corruption:
https://bugs.chromium.org/p/v8/issues/detail?id=12921
PR-URL: https://github.com/nodejs/node/pull/38905
Refs: https://github.com/nodejs/node/issues/35711
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
`test/parallel/test-http-agent-no-wait.js` is basically a duplicate of
`test/parallel/test-http-client-close-with-default-agent.js`, remove it.
PR-URL: https://github.com/nodejs/node/pull/44051
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Feng Yu <F3n67u@outlook.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
