Promote DEP0195 from documentation-only to a runtime deprecation.
Calling node:http constructors without `new` now emits DEP0195 via
deprecateInstantiation. This covers Agent, Server, OutgoingMessage,
IncomingMessage, ServerResponse, and ClientRequest.
Update in-tree tests that called Server/Agent without `new` to use
the keyword, and add a dedicated DEP0195 coverage test.
Refs: https://github.com/nodejs/node/pull/58518
Assisted-by: Grok
Signed-off-by: Yagiz Nizipli <yagiz@nizipli.com>
PR-URL: https://github.com/nodejs/node/pull/64853
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Gürgün Dayıoğlu <hey@gurgun.day>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Add ZIP archive support to the node:zlib module through three classes
and a set of helpers:
- ZipEntry: a single archive member, with buffered reads (content()),
bounded-memory streaming reads (contentIterator()), and
create()/createStream() for building members.
- ZipFile: random access to an archive backed by a file descriptor,
reading members lazily without retaining their content and writing
new members in place; opened with open()/openSync().
- ZipBuffer: a zero-copy, in-memory view over an archive already held
in a Buffer.
createZipArchive() serializes a sequence of entries into an archive
byte stream, and setMaxZipContentSize() bounds the default in-memory
decompression size. Every operation has both an asynchronous and a
synchronous form.
Signed-off-by: Philipp Dunkel <pip@pipobscure.com>
PR-URL: https://github.com/nodejs/node/pull/64339
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Aviv Keller <me@aviv.sh>
Heap dumps are used for analyzing the relationship between
objects that keep each other alive, so that retainers of
memory can be detected and memory leaks fixed.
6e60ab744e broke this for a wide range of `BaseObject`
instances. Marking all `BaseObject`s, including weak ones,
as children of `Realm` and `Environment` instances gives
the incorrect impression that they are held alive by those
objects, effectively hiding the "real" set of strong roots
that keep other objects alive through GC.
An upcoming change in V8 will allow us to represent this
relationship between `Realm` and `Environment` and its
`BaseObject` and `CppgcMixin` instances properly.
Refs: https://github.com/v8/v8/commit/e37cadf1143a8c5bbe44c0408186b5a26cc23863
Refs: https://github.com/nodejs/node/pull/57417
Signed-off-by: Anna Henningsen <anna@addaleax.net>
PR-URL: https://github.com/nodejs/node/pull/63842
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Route the native backing of Buffer.prototype.copy (CopyImpl, the `_copy`
binding) through V8's new v8::ArrayBuffer::CopyArrayBufferBytes API
(added in the preceding commit) instead of materializing an
ArrayBufferViewContents and doing a manual memmove. This speeds up
partial copies (sourceStart > 0). All copies now go through this
binding: the previous %TypedArray%.prototype.set fast-path for
whole-buffer copies is dropped, since it would throw on a detached or
immutable target rather than report a 0-byte no-op, and the benchmarks
below show the native path is comparable for that case.
When both sides are backed by a SharedArrayBuffer the relaxed-atomic
overload is used, which honors the SharedArrayBuffer memory model.
Mixed copies (one SharedArrayBuffer, one ArrayBuffer) use the regular
overload.
copy() now reports the number of bytes actually copied, as returned by
V8: 0 when the target is backed by a detached or immutable ArrayBuffer.
The copy is then a no-op rather than a write to read-only memory.
The native binding now plumbs byte offsets and the copied-byte count
through as size_t, passed across the fast/slow API boundary as doubles
(exact for integer values below 2^53), so copies that cross the 4 GiB
boundary are no longer truncated to 32 bits.
buffer-copy.js vs node v26.3.0 (x64, 30 runs):
partial=false bytes=1024: +7.91% (***)
partial=false bytes=128: +0.17%
partial=false bytes=8: -0.89%
partial=true bytes=1024: +22.33% (***)
partial=true bytes=128: +19.58% (***)
partial=true bytes=8: +18.70% (***)
This supersedes the prototype in
https://github.com/nodejs/node/pull/62491, which added a bespoke
ArrayBufferView::FastCopy instead of using the upstream-friendly
CopyArrayBufferBytes API.
Adds SharedArrayBuffer and immutable-ArrayBuffer coverage to the buffer
copy tests, plus a pummel regression test for copies larger than 2^32
bytes.
Refs: https://github.com/nodejs/node/issues/55422
Signed-off-by: Robert Nagy <ronagy@icloud.com>
Assisted-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PR-URL: https://github.com/nodejs/node/pull/63828
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: René <contact.9a5d6388@renegade334.me.uk>
This enables v8_enable_seeded_array_index_hash and add a test for it.
Fixes: https://hackerone.com/reports/3511792
deps: V8: backport 0a8b1cdcc8b2
Original commit message:
implement rapidhash secret generation
Bug: 409717082
Change-Id: I471f33d66de32002f744aeba534c1d34f71e27d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6733490
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: snek <snek@chromium.org>
Cr-Commit-Position: refs/heads/main@{#101499}
Refs: https://github.com/v8/v8/commit/0a8b1cdcc8b243c62cf045fa8beb50600e11758a
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
deps: V8: backport 185f0fe09b72
Original commit message:
[numbers] Refactor HashSeed as a lightweight view over ByteArray
Instead of copying the seed and secrets into a struct with value
fields, HashSeed now stores a pointer pointing either into the
read-only ByteArray, or the static default seed for off-heap
HashSeed::Default() calls. The underlying storage is always
8-byte aligned so we can cast it directly into a struct.
Change-Id: I5896a7f2ae24296eb4c80b757a5d90ac70a34866
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7609720
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105531}
Refs: https://github.com/v8/v8/commit/185f0fe09b72fb869fdcf9a89f40ff2295436bca
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
deps: V8: backport 1361b2a49d02
Original commit message:
[strings] improve array index hash distribution
Previously, the hashes stored in a Name's raw_hash_field for decimal
numeric strings (potential array indices) consist of the literal
integer value along with the length of the string. This means
consecutive numeric strings can have consecutive hash values, which
can lead to O(n^2) probing for insertion in the worst case when e.g.
a non-numeric string happen to land in the these buckets.
This patch adds a build-time flag v8_enable_seeded_array_index_hash that
scrambles the 24-bit array-index value stored in a Name's raw_hash_field
to improve the distribution.
x ^= x >> kShift; x = (x * m1) & kMask; // round 1
x ^= x >> kShift; x = (x * m2) & kMask; // round 2
x ^= x >> kShift; // finalize
To decode, apply the same steps with the modular inverses of m1 and m2
in reverse order.
x ^= x >> kShift; x = (x * m2_inv) & kMask; // round 1
x ^= x >> kShift; x = (x * m1_inv) & kMask; // round 2
x ^= x >> kShift; // finalize
where kShift = kArrayIndexValueBits / 2, kMask = kArrayIndexValueMask,
m1, m2 (both odd) are the lower bits of the rapidhash secrets, m1_inv,
m2_inv (modular inverses) are precomputed modular inverse of m1 and m2.
The pre-computed values are appended to the hash_seed ByteArray in
ReadOnlyRoots and accessed in generated code to reduce overhead.
In call sites that don't already have access to the seeds, we read them
from the current isolate group/isolate's read only roots.
To consolidate the code that encode/decode these hashes, this patch
adds MakeArrayIndexHash/DecodeArrayIndexFromHashField in C++ and CSA
that perform seeding/unseeding if enabled, and updates places where
encoding/decoding of array index is needed to use them.
Bug: 477515021
Change-Id: I350afe511951a54c4378396538152cc56565fd55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7564330
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105596}
Refs: https://github.com/v8/v8/commit/1361b2a49d020a718dc5495713eae0fa67d697b9
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
deps: V8: cherry-pick aac14dd95e5b
Original commit message:
[string] add 3rd round to seeded array index hash
Since we already have 3 derived secrets, and arithmetics are
relatively cheap, add a 3rd round to the xorshift-multiply
seeding scheme. This brings the bias from ~3.4 to ~0.4.
Bug: 477515021
Change-Id: I1ef48954bcee8768d8c90db06ac8adb02f06cebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7655117
Reviewed-by: Chengzhong Wu <cwu631@bloomberg.net>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#105824}
Refs: https://github.com/v8/v8/commit/aac14dd95e5be0d487eba6bcdaf9cef4f8bd806c
PR-URL: https://github.com/nodejs-private/node-private/pull/834
CVE-ID: CVE-2026-21717
deps: V8: backport 185f0fe09b72
Original commit message:
[numbers] Refactor HashSeed as a lightweight view over ByteArray
Instead of copying the seed and secrets into a struct with value
fields, HashSeed now stores a pointer pointing either into the
read-only ByteArray, or the static default seed for off-heap
HashSeed::Default() calls. The underlying storage is always
8-byte aligned so we can cast it directly into a struct.
Change-Id: I5896a7f2ae24296eb4c80b757a5d90ac70a34866
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7609720
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105531}
Refs: https://github.com/v8/v8/commit/185f0fe09b72fb869fdcf9a89f40ff2295436bca
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
deps: V8: backport 1361b2a49d02
Original commit message:
[strings] improve array index hash distribution
Previously, the hashes stored in a Name's raw_hash_field for decimal
numeric strings (potential array indices) consist of the literal
integer value along with the length of the string. This means
consecutive numeric strings can have consecutive hash values, which
can lead to O(n^2) probing for insertion in the worst case when e.g.
a non-numeric string happen to land in the these buckets.
This patch adds a build-time flag v8_enable_seeded_array_index_hash that
scrambles the 24-bit array-index value stored in a Name's raw_hash_field
to improve the distribution.
x ^= x >> kShift; x = (x * m1) & kMask; // round 1
x ^= x >> kShift; x = (x * m2) & kMask; // round 2
x ^= x >> kShift; // finalize
To decode, apply the same steps with the modular inverses of m1 and m2
in reverse order.
x ^= x >> kShift; x = (x * m2_inv) & kMask; // round 1
x ^= x >> kShift; x = (x * m1_inv) & kMask; // round 2
x ^= x >> kShift; // finalize
where kShift = kArrayIndexValueBits / 2, kMask = kArrayIndexValueMask,
m1, m2 (both odd) are the lower bits of the rapidhash secrets, m1_inv,
m2_inv (modular inverses) are precomputed modular inverse of m1 and m2.
The pre-computed values are appended to the hash_seed ByteArray in
ReadOnlyRoots and accessed in generated code to reduce overhead.
In call sites that don't already have access to the seeds, we read them
from the current isolate group/isolate's read only roots.
To consolidate the code that encode/decode these hashes, this patch
adds MakeArrayIndexHash/DecodeArrayIndexFromHashField in C++ and CSA
that perform seeding/unseeding if enabled, and updates places where
encoding/decoding of array index is needed to use them.
Bug: 477515021
Change-Id: I350afe511951a54c4378396538152cc56565fd55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7564330
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105596}
Refs: https://github.com/v8/v8/commit/1361b2a49d020a718dc5495713eae0fa67d697b9
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
deps: V8: cherry-pick aac14dd95e5b
Original commit message:
[string] add 3rd round to seeded array index hash
Since we already have 3 derived secrets, and arithmetics are
relatively cheap, add a 3rd round to the xorshift-multiply
seeding scheme. This brings the bias from ~3.4 to ~0.4.
Bug: 477515021
Change-Id: I1ef48954bcee8768d8c90db06ac8adb02f06cebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7655117
Reviewed-by: Chengzhong Wu <cwu631@bloomberg.net>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#105824}
Refs: https://github.com/v8/v8/commit/aac14dd95e5be0d487eba6bcdaf9cef4f8bd806c
Replace the domain-based error handling with AsyncLocalStorage and
setUncaughtExceptionCaptureCallback. This removes the REPL's dependency
on the deprecated domain module while preserving all existing behavior:
- Synchronous errors during eval are caught and displayed
- Async errors (setTimeout, promises, etc.) are caught via the
uncaught exception capture callback
- Top-level await errors are caught and displayed
- The REPL continues operating after errors
- Multiple REPL instances can coexist with errors routed correctly
Changes:
- Use AsyncLocalStorage to track which REPL instance owns an async
context, replacing domain's automatic async tracking
- Add setupExceptionCapture() to install
setUncaughtExceptionCaptureCallback for catching async errors and
routing them to the correct REPL
- Extract error handling logic into REPLServer.prototype._handleError()
- Wrap eval execution in replContext.run() for async context tracking
- Update newListener protection to check AsyncLocalStorage context
- Throw ERR_INVALID_ARG_VALUE if options.domain is passed
PR-URL: https://github.com/nodejs/node/pull/61227
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
This is both valuable as a diagnostic tool and as a way to inform
the JS runtime about external allocations.
Currently, this is a feature only enabled in the statically linked
builds of zstd, so with `--shared-zstd`, we fall back to the
non-tracking variant.
PR-URL: https://github.com/nodejs/node/pull/61717
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
By the time the response event is emitted on the client's side, the
file may have already been fully piped and the stream pipe
may have been destroyed, so the test should not look for the
stream pipe in the snapshot.
PR-URL: https://github.com/nodejs/node/pull/58148
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This makes sure that the tests are run on actual heap snapshots
and prints out missing paths when it cannot be found, which
makes failures easier to debug, and removes the unnecessary
requirement for BaseObjects to be root - which would make
the heap snapshot containment view rather noisy and is not
conceptually correct, since they are actually held by the
BaseObjectList held by the realms.
PR-URL: https://github.com/nodejs/node/pull/57417
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Since `common/crypto` already exists, it makes sense to keep
crypto-related utilities there. The only exception being
common.hasCrypto which is needed up front to determine
if tests should be skipped.
Eliminate the redundant check in hasFipsCrypto and just
use crypto.getFips() directly where needed.
PR-URL: https://github.com/nodejs/node/pull/56714
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
As f9bfe785ee already did for a regular test, replace `python` with
`python3` in the only `pummel` test spawning it so that it can be run on
platforms that don't provide a `python` binary anymore, like modern
macOS or some Linux distributions (e.g. Fedora) without specifying a
`PYTHON` env var.
PR-URL: https://github.com/nodejs/node/pull/53057
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: James M Snell <jasnell@gmail.com>
Filip Skokan