Try to match a test by name prefixed with all its ancestors
to ensure uniqueness of the name
Fixes: https://github.com/nodejs/node/issues/46728
PR-URL: https://github.com/nodejs/node/pull/51577
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Previously the test assumes that when the queued finalizer is run,
it must be run at a point where env->can_call_into_js() is false
(typically, during Environment shutdown), which is not certain.
If GC kicks in early and the second pass finalizer is queued before
the event loop runs the check callbacks, the finalizer would then
be called in check callbacks (via native immediates), where
the finalizer can still call into JS. Essentially, addons can't
make assumptions about where the queued finalizer would be called.
This patch updates the assertions in the test to account for that.
PR-URL: https://github.com/nodejs/node/pull/51898
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Functions registered with `addSerializeCallback()` can access and call
`process.cwd()`. b7d836e2c7 accounted for the fact that it is
necessary to reset the cwd cache after the snapshot builder script has
run, but did not account for possible accesses from serialization
callbacks. To properly account for these, add a deserialization
callback as well.
As a related drive-by fix, also mention the execution order of
callbacks in the documentation.
Refs: https://github.com/nodejs/node/pull/49684
PR-URL: https://github.com/nodejs/node/pull/51901
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Previously, a value seen in 'actual' would be serialized as a circular
reference if it had also appeared in 'expected'.
PR-URL: https://github.com/nodejs/node/pull/51851
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
PR-URL: https://github.com/nodejs/node/pull/51331
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This patch introduces a helper crypto.hash() that computes
a digest from the input at one shot. This can be 1.2-1.6x faster
than the object-based createHash() for smaller inputs (<= 5MB)
that are readily available (not streamed) and incur less memory
overhead since no intermediate objects will be created.
PR-URL: https://github.com/nodejs/node/pull/51044
Refs: https://github.com/nodejs/performance/issues/136
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
PR-URL: https://github.com/nodejs/node/pull/50405
Reviewed-By: Matthew Aitken <maitken033380023@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Deokjin Kim <deokjin81.kim@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Otherwise NODE_V8_COVERAGE would crash in snapshot tests because V8
cannot serialize the leftover debug infos. This ensures that we clean
them all up before serialization.
PR-URL: https://github.com/nodejs/node/pull/51815
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
If the server is not referenced, it might go away too soon
and the client may not get enough ends for it to close
itself, resulting a timeout.
This patch updates the test to simply close the server when
enough requests have been processed, and keep the server
referenced while the test is ongoing.
Drive-by: add more logs to facilitate debugging.
PR-URL: https://github.com/nodejs/node/pull/51863
Refs: https://github.com/nodejs/reliability/issues/791
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The child process should not inherit NODE_V8_COVERAGE because
that clobbers the inspector output the test is checking.
PR-URL: https://github.com/nodejs/node/pull/51816
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
The internal binding profiler is loaded if the test is run with
NODE_V8_COVERAGE.
PR-URL: https://github.com/nodejs/node/pull/51816
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
The recursive fs watch tests that mutate the watched folder
immediately after fs.watch() returns are all flaking in the
CI while the others that mutate the folder with a bit of delay
aren't flaking. So this patch adds a bit of delay for the rest
of the tests to deflake them.
PR-URL: https://github.com/nodejs/node/pull/51842
Refs: https://github.com/nodejs/reliability/issues/790
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The child processes are supposed to get 4 messages (2 ends, 2 writes).
Previously the mustCall() wrapping the message listener attempts
to match exactly 1 invocation which is bound to fail but could be
swallowed if the child happens to be killed before the exit event
is fired for the mustCall() check to work. In the CI, on some
machines the kill() could happen after the child process finishes
with the mustCall() check, resulting in EPERM errors in kill().
This patch fixes the mustCall() checks (updating the expected
invocation count to 4) and swallow the errors when kill() fails,
which should be fine because they are only there for cleanup.
PR-URL: https://github.com/nodejs/node/pull/51841
Refs: https://github.com/nodejs/node/issues/51813
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Move the child process code into a fixture and split the test
so that it can be run in parallel and it's easier to identify
where the failure is coming from. Also use the
spawnSyncAndExitWithoutError() utility so that the test shows
complete information on failure.
Instead of marking all the wasi tests as flaky, only mark the
wasi-poll one which is flaking in the CI now.
PR-URL: https://github.com/nodejs/node/pull/51836
Refs: https://github.com/nodejs/node/issues/51822
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
`NodeRuntime.waitingForDebugger` is a new Inspector Protocol event that
will fire when the process being inspected is waiting for the debugger
(for example, when `inspector.waitForDebugger()` is called). This allows
inspecting processes to know when the inspected process is waiting for a
`Runtime.runIfWaitingForDebugger` message to resume execution. It allows
tooling to resume execution of the inspected process as soon as it deems
necessary, without having to guess if the inspected process is waiting
or not, making the workflow more deterministic. With a more
deterministic workflow, it is possible to update Node.js core tests to
avoid race conditions that can cause flakiness. Therefore, tests were
also changed as following:
* Remove no-op Runtime.runIfWaitingForDebugger from tests that don't
need it
* Use NodeRuntime.waitingForDebugger in all tests that need
Runtime.runIfWaitingForDebugger, to ensure order of operations is
predictable and correct
* Simplify test-inspector-multisession-ws
There might be value in adding `NodeWorker.waitingForDebugger` in a
future patch, but as of right now, no Node.js core inspector tests using
worker threads are not failing due to race conditions.
Fixes: https://github.com/nodejs/node/issues/34730
PR-URL: https://github.com/nodejs/node/pull/51560
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/51663
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Adrian Estrada <edsadr@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
The webpage at the URL referenced by `node --inspect` was retitled when
it was recently moved.
Update the test to match the new title "Debugging Node.js" (formerly
"Debugging Guide").
Refs: https://github.com/nodejs/nodejs.org/pull/6265
PR-URL: https://github.com/nodejs/node/pull/51693
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Within Node.js, attempt to determine if libuv is using io_uring. If it
is, disable process.setuid() and other user identity setters.
We cannot fully prevent users from changing the process's user identity,
but this should still prevent some accidental, dangerous scenarios.
PR-URL: https://github.com/nodejs-private/node-private/pull/528
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2024-22017
Use encodeUtf8String from the encoding_binding internal binding to
convert the result of path.resolve() to a Uint8Array instead of using
Buffer.from(), whose result can be manipulated by the user by
monkey-patching internals such as Buffer.prototype.utf8Write.
HackerOne report: https://hackerone.com/reports/2218653
PR-URL: https://github.com/nodejs-private/node-private/pull/497
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2024-21896
This patch adds support for `sea.getRawAsset()` which is
similar to `sea.getAsset()` but returns the raw asset
in an array buffer without copying. Users should avoid
writing to the returned array buffer. If the injected
section is not marked as writable or not aligned,
writing to the raw asset is likely to result in a crash.
PR-URL: https://github.com/nodejs/node/pull/50960
Refs: https://github.com/nodejs/single-executable/issues/68
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
With this patch:
Users can now include assets by adding a key-path dictionary
to the configuration as the `assets` field. At build time, Node.js
would read the assets from the specified paths and bundle them into
the preparation blob. In the generated executable, users can retrieve
the assets using the `sea.getAsset()` and `sea.getAssetAsBlob()` API.
```json
{
"main": "/path/to/bundled/script.js",
"output": "/path/to/write/the/generated/blob.blob",
"assets": {
"a.jpg": "/path/to/a.jpg",
"b.txt": "/path/to/b.txt"
}
}
```
The single-executable application can access the assets as follows:
```cjs
const { getAsset } = require('node:sea');
// Returns a copy of the data in an ArrayBuffer
const image = getAsset('a.jpg');
// Returns a string decoded from the asset as UTF8.
const text = getAsset('b.txt', 'utf8');
// Returns a Blob containing the asset.
const blob = getAssetAsBlob('a.jpg');
```
Drive-by: update the documentation to include a section dedicated
to the injected main script and refer to it as "injected main
script" instead of "injected module" because it's a script, not
a module.
PR-URL: https://github.com/nodejs/node/pull/50960
Refs: https://github.com/nodejs/single-executable/issues/68
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
This patch adds support for using
`vm.constants.USE_MAIN_CONTEXT_DEFAULT_LOADER` as
`importModuleDynamically` in all APIs that take the option
except `vm.SourceTextModule`. This allows users to have a shortcut
to support dynamic import() in the compiled code without missing
the compilation cache if they don't need customization of the
loading process. We emit an experimental warning when the
`import()` is actually handled by the default loader through
this option instead of requiring `--experimental-vm-modules`.
In addition this refactors the documentation for
`importModuleDynamically` and adds a dedicated section for it
with examples.
`vm.SourceTextModule` is not supported in this patch because
it needs additional refactoring to handle `initializeImportMeta`,
which can be done in a follow-up.
PR-URL: https://github.com/nodejs/node/pull/51244
Fixes: https://github.com/nodejs/node/issues/51154
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
