This parameter was always being set to `nullptr` by its callers, either
explicitly or implicitly via the default argument. It was also buggy, as
in some cases it wouldn't be written to, potentially leaking stack
memory (see the early returns in `StringBytes::WriteUCS2`). Remove it
entirely.
PR-URL: https://github.com/nodejs/node/pull/44092
Reviewed-By: Feng Yu <F3n67u@outlook.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
A recent pull request changed this method to throw when the buffer was
too big, but this meant that the `free` finalizer would never get
called, leading to a memory leak.
A previous version of this diff included a test provoking this behavior
with `v8.serialize`, but it unfortunately kept triggering the OOM
killer, so it was removed.
Refs: https://github.com/nodejs/node/pull/40243
PR-URL: https://github.com/nodejs/node/pull/43938
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The connection between the JS land zero fill toggle and the
C++ one in the NodeArrayBufferAllocator gets lost if the toggle
is deserialized from the snapshot, because V8 owns the underlying
memory of this toggle. This resets the connection at pre-execution.
PR-URL: https://github.com/nodejs/node/pull/32984
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
We currently mark a number of `ArrayBuffer`s as not transferable,
including the `Buffer` pool and ones with finalizers provided
by C++ addons.
There is no good reason to assume that userland code might not
encounter similar problems, for example when doing `ArrayBuffer`
pooling similar to ours. Therefore, provide an API that lets
userland code also mark objects as not transferable.
PR-URL: https://github.com/nodejs/node/pull/33979
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Release `Buffer` and `ArrayBuffer` instances that were created through
our addon APIs and have finalizers attached to them only after V8 has
called the deleter callback passed to the `BackingStore`, instead of
relying on our own GC callback(s).
This fixes the following race condition:
1. Addon code allocates pointer P via `malloc`.
2. P is passed into `napi_create_external_buffer` with a finalization
callback which calls `free(P)`. P is inserted into V8’s global array
buffer table for tracking.
3. The finalization callback is executed on GC. P is freed and returned
to the allocator. P is not yet removed from V8’s global array
buffer table. (!)
4. Addon code attempts to allocate memory once again. The allocator
returns P, as it is now available.
5. P is passed into `napi_create_external_buffer`. P still has not been
removed from the v8 global array buffer table.
6. The world ends with `Check failed: result.second`.
Since our API contract is to call the finalizer on the JS thread on
which the `ArrayBuffer` was created, but V8 may call the `BackingStore`
deleter callback on another thread, fixing this requires posting
a task back to the JS thread.
Refs: https://github.com/nodejs/node/issues/32463#issuecomment-625877175
Fixes: https://github.com/nodejs/node/issues/32463
PR-URL: https://github.com/nodejs/node/pull/33321
Reviewed-By: James M Snell <jasnell@gmail.com>
Node codebase has evolved a lot in the more than 10 years of its
existence. As more features (and code) have been added, changed,
removed, it's sometimes hard to keep track of what gets used and what
not.
This commits attempts to clean some of those potentially left-over
headers using suggestions from include-what-you-use
Refs: https://github.com/nodejs/node/issues/27531
PR-URL: https://github.com/nodejs/node/pull/30328
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This can be useful to create `Buffer` instances for already-existing
`ArrayBuffer`s, e.g. ones created manually from a backing store
with a free callback (of which our variant in the public API has
some limitations).
PR-URL: https://github.com/nodejs/node/pull/30476
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: James M Snell <jasnell@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>
`v8::Global` is essentially a nicer variant of `node::Persistent` that,
in addition to reset-on-destroy, also implements move semantics.
This commit makes the necessary replacements, removes
`node::Persistent` and (now-)unnecessary inclusions of the
`node_persistent.h` header, and makes some of the functions that
take Persistents as arguments more generic so that they work with all
`v8::PersistentBase` flavours.
PR-URL: https://github.com/nodejs/node/pull/27287
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This condition was incorrect. We currently take the fallback
path in default Node builds, which always works, but may come with
some overhead, whereas the intention was that we use the fast path
in this condition.
This is causing issues for embedders, because we would erroneously
try to take the fast path when they don’t provide a Node.js-style
`ArrayBufferAlloactor`, and crash as a consequence of that.
This also requires us to relax the check in the debugging ArrayBuffer
allocator a bit, because since d117e41e50, 0-sized ArrayBuffers
may actually point to allocations of size 1. Previously, that wasn’t
caught because the fallback path circumvented our ArrayBufferAllocator.
Refs: https://github.com/nodejs/node/commit/84e02b178ad14fae0df2a514e8a39bfa50ffdc2d#r33116006
PR-URL: https://github.com/nodejs/node/pull/27174
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Use a RAII approach by default, and make it possible for embedders
to use the `ArrayBufferAllocator` directly as a V8
`ArrayBuffer::Allocator`, e.g. when passing to `Isolate::CreateParams`
manually.
PR-URL: https://github.com/nodejs/node/pull/26525
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Keyhan Vakil