Use a symbol on the bindings object to store the public resource object,
rather than a `v8::Global` Persistent. This has several advantages:
- It’s harder to inadvertently create memory leaks this way.
The garbage collector sees the `AsyncWrap` → resource link like
a regular JS property, and can collect the objects as a group,
even if the resource object should happen to point back to the
`AsyncWrap` object.
- This will make it easier in the future to use `owner_symbol` for
this purpose, which is generally the direction we should be moving
the `async_hooks` API into (i.e. using more public objects instead
of letting internal wires stick out).
PR-URL: https://github.com/nodejs/node/pull/31745
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Minwoo Jung <nodecorelab@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
`AddToIncomingQueue()` relies on `owner_` only being modified with
`mutex_` being locked, but in these two places, that didn’t happen.
Modify them to use `Detach()` instead, which has the same effect
as setting `owner_ = nullptr` here, but does it with proper locking.
This race condition probably only shows up in practice when Node.js
is compiled in debug mode, because the compiler eliminates the
duplicate load in `AddToIncomingQueue()` when compiling with
optimizations enabled.
PR-URL: https://github.com/nodejs/node/pull/33429
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
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>
In some situations, it can be useful to use threadsafe callbacks
on an `Environment` to perform cleanup operations that should run
even when the process would otherwise be ending.
PR-URL: https://github.com/nodejs/node/pull/33320
Reviewed-By: James M Snell <jasnell@gmail.com>
Add regression tests for the case in which an async_hook is enabled
inside a Worker thread and `process.exit()` is called during the
async part of an async function.
This commit includes multiple tests that seem like they should all
crash in a similar way, but interestingly don’t. In particular, it’s
surprising that the presence of a statement after `process.exit()`
in a function has an effect on the kind of crash that’s being
exhibited (V8 DCHECK vs. assertion in our own code) and the
circumstances under which it crashes (e.g. the -1 and -2 tests
can be “fixed” by reverting 13c5a1629c, although they
should have the same behavior as the -3 and -4 tests).
PR-URL: https://github.com/nodejs/node/pull/33347
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Termination exceptions are similar to uncaught exceptions in that they
should clear the async id stack, because no ongoing async callbacks
will be brought to completion when execution terminates.
Previously, there was a check that made sure that that happened when
the termination occurred during the callback itself, but no such check
was in place for the case that the termination occurred during
microtasks started by them. This commit adds such a check, both for
microtasks and the `nextTick` queue. The latter addition doesn’t fix
a crash, but still makes sense conceptually.
The condition here is also flipped from applying only on Worker threads
to also applying on the main thread, and setting the `failed_` flag
rather than reading it. The former makes sense because the public C++
`Stop(env)` API can have the same effect as worker thread termination,
but on the main thread rather than a Worker thread.
PR-URL: https://github.com/nodejs/node/pull/33347
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
libuv does not expect concurrent operations on `uv_dir_t` instances,
and will gladly create memory leaks, corrupt data, or crash the
process.
This patch forbids that, and:
- Makes sure that concurrent async operations are run sequentially
- Throws an exception if sync operations are attempted during an
async operation
The assumption here is that a thrown exception is preferable to
a potential hard crash.
This fully fixes flakiness from `parallel/test-fs-opendir` when
run under ASAN.
PR-URL: https://github.com/nodejs/node/pull/33274
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
A call into JS can schedule another operation on the same `uv_dir_t`.
In particular, when the handle is closed from the callback for a
directory read operation, there previously was a race condition window:
1. A `dir.read()` operation is submitted to libuv
2. The read operation is finished by libuv, calling `AfterDirRead()`
3. We call into JS
4. JS calls dir.close()
5. libuv posts the close request to a thread in the pool
6. The close request runs, destroying the directory handle
7. `AfterDirRead()` is being exited.
Exiting the `FSReqAfterScope` in step 7 attempts to destroy the original
uv_fs_t` from step 1, which now points to an `uv_dir_t` that has
already been destroyed in step 5.
By forcing the `FSReqAfterScope` to clean up before we call into JS,
we can be sure that no other operations on the same `uv_dir_t` are
submitted concurrently.
This addresses issues observed when running with ASAN/valgrind.
PR-URL: https://github.com/nodejs/node/pull/33274
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This test can fail when run in parallel with test-process-title-cli,
which also sets the process title, which is global state on Windows.
Example failure (note that `foo` does not appear in test-process-title
but in test-process-title-cli):
not ok 1727 parallel/test-process-title
---
duration_ms: 0.156
severity: fail
exitcode: 1
stack: |-
assert.js:103
throw new AssertionError(obj);
^
AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
+ actual - expected
+ 'foo'
- 'd:\\a\\node\\node\\out\\Release\\node.exe'
at Object.<anonymous> (d:\a\node\node\test\parallel\test-process-title.js:22:1)
at Module._compile (internal/modules/cjs/loader.js:1176:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1196:10)
at Module.load (internal/modules/cjs/loader.js:1040:32)
at Function.Module._load (internal/modules/cjs/loader.js:929:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
at internal/main/run_main_module.js:17:47 {
generatedMessage: true,
code: 'ERR_ASSERTION',
actual: 'foo',
expected: 'd:\\a\\node\\node\\out\\Release\\node.exe',
operator: 'strictEqual'
}
...
(from https://github.com/nodejs/node/runs/628144750?check_suite_focus=true)
PR-URL: https://github.com/nodejs/node/pull/33150
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Mostly, this introduces a pattern that makes sure that if a custom
error is reported, `stopped_` will be set to `true` correctly in
every cast, which was previously missing for the
`NewContext().IsEmpty()` case (which led to a hard crash from the
`Worker` destructor).
This also leaves TODO comments for a few cases in which
`ERR_WORKER_OUT_OF_MEMORY` was not used in accordance with the
documentation for that error code (or according to its intention).
Fixing that is semver-major.
PR-URL: https://github.com/nodejs/node/pull/33084
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The assumption here is that decomposed characters render like their
composed character equivalents, and that working with the former
comes with a risk of over-estimating string widths given that
we compute them on a per-code-point basis. The regression test
added here (한글 vs 한글) is an example of that happening.
PR-URL: https://github.com/nodejs/node/pull/33052
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This fixes the following crash on Windows for me. I don't know
why this I only started to see this now, but anyway, the new timeout
value is still longer than a week and a half.
File "tools/test.py", line 1725, in <module>
sys.exit(Main())
File "tools/test.py", line 1701, in Main
if RunTestCases(cases_to_run, options.progress, \
options.j, options.flaky_tests):
File "tools/test.py", line 923, in RunTestCases
return progress.Run(tasks)
File "tools/test.py", line 145, in Run
thread.join(timeout=10000000)
File "C:\Users\anna\AppData\Local\Programs\Python\Python38-32\ \
lib\threading.py", line 1015, in join
self._wait_for_tstate_lock(timeout=max(timeout, 0))
File "C:\Users\anna\AppData\Local\Programs\Python\Python38-32\ \
lib\threading.py", line 1027, in _wait_for_tstate_lock
elif lock.acquire(block, timeout):
OverflowError: timeout value is too large
PR-URL: https://github.com/nodejs/node/pull/32868
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Zeyu Yang <himself65@outlook.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
This simplifies the code significantly, and removes the dependency of
the inspector code on the availability of a `MultiIsolatePlatform`
(by removing the dependency on a platform altogether).
It also fixes a memory leak that occurs when `RequestInterrupt()`
is used, but the interrupt handler is never called before the Isolate
is destroyed.
One downside is that this leads to a slight change in timing, because
inspector messages are not dispatched in a re-entrant way. This means
having to harden one test to account for that possibility by making
sure that the stack is always clear through a `setImmediate()`.
This does not affect the assertion made by the test, which is that
messages will not be delivered synchronously while other code is
executing.
https://github.com/nodejs/node/issues/32415
PR-URL: https://github.com/nodejs/node/pull/32523
Reviewed-By: Matheus Marchini <mat@mmarchini.me>
Reviewed-By: James M Snell <jasnell@gmail.com>
Fix this to account for the fact that `Stop()` may already have been
called from a cleanup hook when the `inspector::Agent` is deleted
along with the `Environment`, at which point cleanup hooks are no
longer available.
PR-URL: https://github.com/nodejs/node/pull/32523
Reviewed-By: Matheus Marchini <mat@mmarchini.me>
Reviewed-By: James M Snell <jasnell@gmail.com>
Fix the compile flags so that zlib can run on CPUs that do
not have SSSE3/SSE4.2/etc. Do not compile zlib with flags that
indicate that those features are available, and instead enable
them selectively for functions that use them.
There are probably better way to do this, e.g. through gyp file
modifications as suggested in the issue. However, this patch
should do just fine until that happens.
Fixes: https://github.com/nodejs/node/issues/32553
PR-URL: https://github.com/nodejs/node/pull/32627
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Enable the state associated with the individual bindings, e.g. fs or
http2, to be moved out of the Environment class, in order for these
to be more modular and for Environment to be come less of a collection
of random data fields.
Do this by using a BaseObject as the data for callbacks, which can hold
the per-binding state. By default, no per-binding state is available,
although that can be configured when setting up the binding.
PR-URL: https://github.com/nodejs/node/pull/32538
Reviewed-By: James M Snell <jasnell@gmail.com>
This reverts commit 037ac99ed5.
As flaky CI failures have revealed, this feature was implemented
incorrectly. `stop_sub_worker_contexts()` needs to be called on the
thread on which the `Environment` is currently running, it’s not
thread-safe. The current API requires `Stop()` to be thread-safe,
though.
We could add a new API for this, but unless there’s demand, that’s
probably not necessary as `FreeEnvironment()` will also stop Workers,
which is commonly the next action on an `Environment` instance after
having `Stop()` called on it.
Refs: https://github.com/nodejs/node/pull/32531
PR-URL: https://github.com/nodejs/node/pull/32623
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
This addresses some long-standing TODOs by Joyee and me about
making the embedder API more powerful and us less reliant on
internal APIs for creating the main thread and Workers.
PR-URL: https://github.com/nodejs/node/pull/30467
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Workers are fully in control of their Isolates, and this helps
avoid a problem with later changes to `CreateEnvironment()`
because now we can run the boostrapping code inside the latter.
PR-URL: https://github.com/nodejs/node/pull/30467
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Make the calls `stop_sub_worker_contexts()`, `RunCleanup()`
part of the public API for easier embedding.
(Note that calling `RunAtExit()` is idempotent because the
at-exit callback queue is cleared after each call.)
PR-URL: https://github.com/nodejs/node/pull/30467
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Anna Henningsen