delta/node-new.git/src/js_native_api_v8.cc, branch docs-fix

n-api: handle weak no-finalizer refs correctly

2020-08-21T13:16:18+00:00

When deleting a weak reference that has no finalizer we must not defer
deletion until the non-existent finalizer gets called.

Fixes: https://github.com/nodejs/node/issues/34731
Signed-off-by: Gabriel Schulhof 

PR-URL: https://github.com/nodejs/node/pull/34839
Reviewed-By: Anna Henningsen 
Reviewed-By: Gus Caplan 
Reviewed-By: James M Snell 
Reviewed-By: Rich Trott

n-api: support type-tagging objects

2020-08-01T01:30:30+00:00

`napi_instanceof()` is insufficient for reliably establishing the data
type to which a pointer stored with `napi_wrap()` or
`napi_create_external()` inside a JavaScript object points. Thus, we
need a way to "mark" an object with a value that, when later retrieved,
can unambiguously tell us whether it is safe to cast the pointer stored
inside it to a certain structure.

Such a check must survive loading/unloading/multiple instances of an
addon, so we use UUIDs chosen *a priori*.

Fixes: https://github.com/nodejs/node/issues/28164
Co-authored-by: Anna Henningsen 
PR-URL: https://github.com/nodejs/node/pull/28237
Reviewed-By: Anna Henningsen 
Reviewed-By: Michael Dawson 
Reviewed-By: Colin Ihrig 
Signed-off-by: Gabriel Schulhof

n-api: simplify bigint-from-word creation

2020-07-31T20:45:25+00:00

Macro `CHECK_MAYBE_EMPTY_WITH_PREAMBLE()` does the work of checking
the `TryCatch` and returning `napi_pending_exception` so this change
reuses it for `napi_create_bigint_words()`.

Signed-off-by: Gabriel Schulhof 
PR-URL: https://github.com/nodejs/node/pull/34554
Reviewed-By: James M Snell 
Reviewed-By: Anna Henningsen 
Reviewed-By: Michael Dawson

n-api: run all finalizers via SetImmediate()

2020-07-24T06:28:09+00:00

Throwing an exception from a finalizer can cause the following fatal
error:

Error: async hook stack has become corrupted (actual: 2, expected: 0)
 1: 0x970b5a node::InternalCallbackScope::~InternalCallbackScope()
    [./node]
 2: 0x99dda0 node::Environment::RunTimers(uv_timer_s*) [./node]
 3: 0x13d8b22  [./node]
 4: 0x13dbe42 uv_run [./node]
 5: 0xa57974 node::NodeMainInstance::Run() [./node]
 6: 0x9dbc17 node::Start(int, char**) [./node]
 7: 0x7f4965417f43 __libc_start_main [/lib64/libc.so.6]
 8: 0x96f4ae _start [./node]

By https://github.com/nodejs/node/issues/34341#issuecomment-658426281,
calling into JS from a finalizer and/or throwing exceptions from there
is not advised, because the stack may or may not be set up for JS
execution. The best solution is to run the user's finalizer from a
`SetImmediate()` callback.

Signed-off-by: Gabriel Schulhof 
Fixes: https://github.com/nodejs/node/issues/34341
PR-URL: https://github.com/nodejs/node/pull/34386
Reviewed-By: James M Snell 
Reviewed-By: Anna Henningsen 
Reviewed-By: Michael Dawson 
Reviewed-By: Juan José Arboleda

n-api: ensure scope present for finalization

2020-06-09T23:17:49+00:00

Refs: https://github.com/nodejs/node-addon-api/issues/722

Ensure a scope is on stack during finalization
as finalization functions can create JS Objects

Signed-off-by: Michael Dawson 

PR-URL: https://github.com/nodejs/node/pull/33508
Reviewed-By: Gabriel Schulhof 
Reviewed-By: James M Snell

napi: fix memory corruption vulnerability

2020-06-02T18:35:51+00:00

Fixes: https://hackerone.com/reports/784186
CVE-ID: CVE-2020-8174
PR-URL: https://github.com/nodejs-private/node-private/pull/195
Reviewed-By: Anna Henningsen 
Reviewed-By: Gabriel Schulhof 
Reviewed-By: Michael Dawson 
Reviewed-By: Colin Ihrig 
Reviewed-By: Rich Trott

n-api: remove `napi_env::CallIntoModuleThrow`

2020-05-28T20:28:56+00:00

Give `napi_env::CallIntoModule` the thrower used by
`CallIntoModuleThrow` as its default second argument. That way we do
not need two different methods on `napi_env` for calling into the
addon.

PR-URL: https://github.com/nodejs/node/pull/33570
Signed-off-by: Gabriel Schulhof 
Reviewed-By: James M Snell 
Reviewed-By: Anna Henningsen 
Reviewed-By: Chengzhong Wu 
Reviewed-By: Michael Dawson

buffer,n-api: release external buffers from BackingStore callback

2020-05-16T10:15:07+00:00

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

buffer,n-api: fix double ArrayBuffer::Detach() during cleanup

2020-04-27T09:16:51+00:00

These calls could fail if the `ArrayBuffer` had already been explicitly
detached at some point in the past.

The necessary test changes already came with 4f523c2c1a1c and could
be ported back to v12.x with a backport of this PR.

Fixes: https://github.com/nodejs/node/issues/33022
Refs: https://github.com/nodejs/node/pull/30551

PR-URL: https://github.com/nodejs/node/pull/33039
Reviewed-By: James M Snell 
Reviewed-By: Chengzhong Wu 
Reviewed-By: Michael Dawson 
Reviewed-By: Gerhard Stöbich 
Reviewed-By: David Carlier 
Reviewed-By: Juan José Arboleda

n-api: detect deadlocks in thread-safe function

2020-04-19T17:07:00+00:00

We introduce status `napi_would_deadlock` to be used as a return status
by `napi_call_threadsafe_function` if the call is made with
`napi_tsfn_blocking` on the main thread and the queue is full.

Fixes: https://github.com/nodejs/node/issues/32615
Signed-off-by: Gabriel Schulhof 
PR-URL: https://github.com/nodejs/node/pull/32860
Reviewed-By: Ben Noordhuis 
Reviewed-By: Michael Dawson 
Reviewed-By: Zeyu Yang