At least one method on a native object is added as a getter,
namely `MessagePort.prototype.onmessage`. When a MessagePort
attempts to call this method from C++ in response to receiving
data, it will first invoke that getter and then call the function.
Since `worker.terminate()` interrupts execution, this means
that the getter may fail (without being faulty code on its own).
This means that at least one test exercising these methods in
combination has been flaky and could have crashed, because
we did not actually check that the getter returns a value
so far, resulting in dereferencing an empty `Local`.
The proper fix for this is to use the non-deprecated overload
of `Get()` and check the result like we should be doing.
Also, as a (related) fix, don’t crash if the method
is not a function but rather something else, like a getter
could provide.
Example test failure: https://ci.nodejs.org/job/node-test-commit-linux-containered/4976/nodes=ubuntu1604_sharedlibs_zlib_x64/console
17:56:56 not ok 1955 parallel/test-worker-dns-terminate
17:56:56 ---
17:56:56 duration_ms: 1.237
17:56:56 severity: crashed
17:56:56 exitcode: -11
17:56:56 stack: |-
PR-URL: https://github.com/nodejs/node/pull/21189
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Scrypt is a password-based key derivation function that is designed to
be expensive both computationally and memory-wise in order to make
brute-force attacks unrewarding.
OpenSSL has had support for the scrypt algorithm since v1.1.0. Add a
Node.js API modeled after `crypto.pbkdf2()` and `crypto.pbkdf2Sync()`.
Changes:
* Introduce helpers for copying buffers, collecting openssl errors, etc.
* Add new infrastructure for offloading crypto to a worker thread.
* Add a `AsyncWrap` JS class to simplify pbkdf2(), randomBytes() and
scrypt().
Fixes: https://github.com/nodejs/node/issues/8417
PR-URL: https://github.com/nodejs/node/pull/20816
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Right now, we crash the process if there are handles remaining
on the event loop when we exit (except for the main thread).
This does not provide a lot of information about causes, though;
in particular, we don’t show which handles are pending and
who own them.
This patch adds debug output to these cases to help with the
situation.
PR-URL: https://github.com/nodejs/node/pull/21238
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Fix an use-after-free bug in the TLS implementation.
If we return from `DoWrite()` with an early error, we should
not be storing the `WriteWrap` object and complete it
again at a later point, when it has already been freed
(because of the write error).
This issue was reported by Jordan Zebor at F5 Networks,
who also helped with investigating this bug and coming
up with a reproduction.
This fixes CVE-2018-7162.
Fixes: https://github.com/nodejs-private/security/issues/189
PR-URL: https://github.com/nodejs-private/node-private/pull/127
Reviewed-By: Evan Lucas <evanlucas@me.com>
It's hypothetically (and with certain V8 flags) possible for the session
to be garbage collected before all the streams are. In that case, trying
to remove the stream from the session will lead to a segfault due to
attempting to access no longer valid memory. Fix this by unsetting the
session on any streams still around when destroying.
PR-URL: https://github.com/nodejs/node/pull/21194
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Added a new struct CallbackBundle to eliminate all
GetInternalField() calls.
The principle is to store all required data inside a C++ struct,
and then store the pointer in the JavaScript object. Before this
change, the required data are stored in the JavaScript object in
3 or 4 seperate pointers. For every napi fun call, 3 of them
have to be fetched out, which are 3 GetInternalField() calls;
after this change, the C++ struct will be directly fetched out
by using v8::External::Value(), which is faster.
Profiling data show that GetInternalField() is slow.
On an i7-4770K (3.50GHz) box, a C++ V8-binding fun call is 8 ns,
before this change, napi fun call is 36 ns; after this change,
napi fun call is 20 ns.
The above data are measured using a modified benchmark in
'benchmark/misc/function_call'. The modification adds an indicator
of the average time of a "chatty" napi fun call (max 50M runs).
This change will speed up chatty case 1.8x (overall), and will cut
down the delay of napi mechanism to approx. 0.5x.
Background: a simple C++ binding function (e.g. receiving little
from JS, doing little and returning little to JS) is called
'chatty' case for JS<-->C++ fun call routine.
This improvement also applies to getter/setter fun calls.
PR-URL: https://github.com/nodejs/node/pull/21072
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
We use the `Isolate*` pointer as the sole identifier
for a V8 Isolate. In some environments (e.g. multi-threaded),
Isolates may be destroyed and new ones created; then, it
may happen that the memory that was previously used for
one `Isolate` can be re-used for another `Isolate`
after the first one has been disposed of.
This check is a little guard against accidentally
re-using the same per-Isolate platform data structure
in such cases, i.e. making sure (to the degree to which
that is possible) that the old `Isolate*` has been properly
unregistered before one at the same memory address is added.
(It’s not 100 % foolproof because the `uv_loop_t*`
pointer value could theoretically be the same as well.)
PR-URL: https://github.com/nodejs/node/pull/21156
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Currently the following compiler warnings are generated:
../src/node_messaging.cc:74:16:
warning: private field 'env_' is not used [-Wunused-private-field]
Environment* env_;
^
../src/node_messaging.cc:75:12:
warning: private field 'msg_' is not used [-Wunused-private-field]
Message* msg_;
^
2 warnings generated.
This commit removes these unused private members.
PR-URL: https://github.com/nodejs/node/pull/20876
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Shingo Inoue <leko.noor@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
While `NumberOfHeapSpaces()` currently returns a constant value,
that is not strictly guaranteed by the V8 API as far as I can tell.
Therefore, caching it globally does not seem appropriate.
(The motivation here is that this squelches warnings which are
produced by concurrency debugging tooling due to the apparent
race conditions when accessing the global variable.)
PR-URL: https://github.com/nodejs/node/pull/20971
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
James M Snell