src: fix hang when joining workers in process.exit() by manzoorwanijk · Pull Request #66171 · nodejs/node

manzoorwanijk · 2026-09-21T10:00:21Z

process.exit() can hang forever when a V8 background job (for example a concurrent Sparkplug or Maglev compile) is parked waiting for the main thread to collect garbage. The exit handler joins the platform workers without disposing the isolate, and only isolate teardown or a main-thread GC wakes such a worker. This makes the main thread perform that GC while it waits for the workers to exit.

Fixes #64274

The test uses --stress-concurrent-allocation plus a threadpool job that uv_library_shutdown() waits on, which parks a worker in CollectionBarrier::AwaitCollectionBackground() before the join. Without the fix it hangs in 20 of 20 local runs; with it, it passes 30 of 30.

This hang stalls our WordPress core builds that end with process.exit() on Node.js 24 (WordPress/wordpress-develop#13608).

github-actions · 2026-09-21T10:01:23Z

Welcome to Node.js, and thank you for your first contribution!

Before review, please take a moment to read:

the guide for first-time contributors
the contribution and automation policies
the pull request guide
the AI use policy
the Code of Conduct

Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal.

manzoorwanijk · 2026-09-21T10:05:48Z

I have a question: Will this fix be backported to v24 when/if it lands?

CC: @addaleax @joyeecheung

codecov · 2026-09-21T12:37:51Z

Codecov Report

❌ Patch coverage is 69.04762% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.42%. Comparing base (dd9777b) to head (e7f8e56).

Files with missing lines	Patch %	Lines
src/node_platform.cc	64.86%	11 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #66171      +/-   ##
==========================================
- Coverage   92.78%   90.42%   -2.36%     
==========================================
  Files         422      791     +369     
  Lines      193692   276617   +82925     
  Branches    29881    53126   +23245     
==========================================
+ Hits       179714   250135   +70421     
- Misses      13650    16871    +3221     
- Partials      328     9611    +9283

Files with missing lines	Coverage Δ
src/api/environment.cc	`79.52% <100.00%> (ø)`
src/node_platform.h	`85.71% <ø> (ø)`
src/node_v8_platform-inl.h	`94.11% <100.00%> (ø)`
src/node_platform.cc	`74.14% <64.86%> (ø)`

... and 495 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

…13 of 30 against 0 of 30 The 28 September list, item 15: find the mechanism, add no timeout. Reproduced, then read off the stuck process: its main thread waits in uv_thread_join under node::DefaultProcessExitHandler, and the one Node thread left sleeps on a condition variable inside V8 — nodejs/node#54918 and #64274, process.exit() joining platform workers while a V8 background job is parked waiting for a GC the exiting thread never runs. The upstream fix (nodejs/node#66171) is unmerged; this machine runs Node 24.12.0. Separated by treatment rather than argued: 30 alternating pairs under the same launch, the proof as shipped hung 13 times after printing its pass, and the same file ending by process.exitCode hung 0 times. The class is 289 process.exit( calls in 147 scripts plus the engine host entries; converting them is its own unit (a script relying on process.exit to cut an open handle would trade this hang for another), recorded with the shape it should take. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ent compilers On Node 24 `process.exit` can deadlock joining V8's platform workers (a concurrent Sparkplug or Maglev compile waits for a GC the main thread never runs), so a run that got Ctrl-C or `sandcastle stop` could write its end and then never exit (nodejs/node#66171, still open). `exitOnSignal` no longer calls `process.exit`: it sets the exit code to 128 + n, emits `exit` once so every listener runs, drops its own listener and re-sends the signal with the default action back. The kernel ends the process, and the shell still sees 129, 130 or 143. `bin/sandcastle` passes `--no-maglev --no-concurrent-sparkplug` on both exec lines; a detached run inherits them through `process.execArgv`. Tests: the signals fixture runs with the launcher's flags, asserts death by the signal, the exit listeners once with 128 + n, and no `process.exit` call; the launcher, mod and notify tests follow the new exec line and the signal death. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

…63788) On Node 24 and 26, process.exit() joins V8's platform workers without disposing the isolate. A concurrent Maglev or Sparkplug compile job parked waiting for a main-thread GC then never finishes, so CLI commands, the hook relay, or a stopping Gateway can sit at 0% CPU forever after printing their output (nodejs/node#64274; fix pending in nodejs/node#66171). Every OpenClaw executable entrypoint (CLI entry, Gateway/service index, native hook relay, macOS node worker) now turns off Maglev and concurrent Sparkplug at startup when it runs as main, matching Node 22's tiering and the existing Vitest policy. Library imports keep stock V8; explicit --maglev or --concurrent-sparkplug flags still win. Testbox A/B (4 vCPU, Node 24.19, e2e CLI child replay, 8-way): 6/1019 hung with defaults, 0/1019 with the policy; re-enabling only Maglev hung 2/1019 and only concurrent Sparkplug 12/944, so both flags are needed.

manzoorwanijk · 2026-10-03T04:10:33Z

Can we please expedite this bug fix?

…enclaw#163788) On Node 24 and 26, process.exit() joins V8's platform workers without disposing the isolate. A concurrent Maglev or Sparkplug compile job parked waiting for a main-thread GC then never finishes, so CLI commands, the hook relay, or a stopping Gateway can sit at 0% CPU forever after printing their output (nodejs/node#64274; fix pending in nodejs/node#66171). Every OpenClaw executable entrypoint (CLI entry, Gateway/service index, native hook relay, macOS node worker) now turns off Maglev and concurrent Sparkplug at startup when it runs as main, matching Node 22's tiering and the existing Vitest policy. Library imports keep stock V8; explicit --maglev or --concurrent-sparkplug flags still win. Testbox A/B (4 vCPU, Node 24.19, e2e CLI child replay, 8-way): 6/1019 hung with defaults, 0/1019 with the policy; re-enabling only Maglev hung 2/1019 and only concurrent Sparkplug 12/944, so both flags are needed.

…nd a time limit Tests that spawned the CLI ran tsx's cli.mjs or .bin/tsx without the launcher's --no-maglev --no-concurrent-sparkplug, so they could hit the Node 24 exit deadlock (nodejs/node#66171), and their spawnSync calls had no timeout, so one stuck exit hung pnpm test, every sandbox gate run and full-check.sh. test/cli-spawn.ts (runKit, runNode, startKit, startNode) reads the flags from bin/sandcastle, runs node with tsx's loader in one process as the launcher does, and kills a child that outlives its limit (60 s, SIGKILL) with the test failing and the command named. Every test that spawned a kit script now uses it, and test/cli-spawn.test.ts refuses a test file that names a tsx entry itself. pnpm test gets --test-timeout=300000, which fails an async hang by name; it cannot interrupt a synchronous spawnSync, which is what the helper's limit is for. Where the ticket left a choice: the helper also covers the Herdr plugin entry (script option) and the non-CLI fixtures that import src/, since the guard test would otherwise need an allowlist for them. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

…enclaw#163788) On Node 24 and 26, process.exit() joins V8's platform workers without disposing the isolate. A concurrent Maglev or Sparkplug compile job parked waiting for a main-thread GC then never finishes, so CLI commands, the hook relay, or a stopping Gateway can sit at 0% CPU forever after printing their output (nodejs/node#64274; fix pending in nodejs/node#66171). Every OpenClaw executable entrypoint (CLI entry, Gateway/service index, native hook relay, macOS node worker) now turns off Maglev and concurrent Sparkplug at startup when it runs as main, matching Node 22's tiering and the existing Vitest policy. Library imports keep stock V8; explicit --maglev or --concurrent-sparkplug flags still win. Testbox A/B (4 vCPU, Node 24.19, e2e CLI child replay, 8-way): 6/1019 hung with defaults, 0/1019 with the policy; re-enabling only Maglev hung 2/1019 and only concurrent Sparkplug 12/944, so both flags are needed. (cherry picked from commit 1aa0aeb) Co-authored-by: RomneyDa <6581799+RomneyDa@users.noreply.github.com>

MikeMcC399 · 2026-10-05T07:55:41Z

Can we please expedite this bug fix?

review wanted PRs that need review. label added for additional visibility

manzoorwanijk · 2026-10-05T08:02:43Z

review wanted PRs that need review. label added for additional visibility

Thank you

PetrKrcek · 2026-10-07T19:19:52Z

Independent reproduction on macOS (Darwin 25.5), Apple Silicon, Node v26.5.0 (Homebrew):

The regression test from this PR (test-process-exit-background-gc.js at 8816d66) hangs 3/3 on v26.5.0 (killed after 30 s); the same child with process.exitCode = 0 instead of process.exit(0) exits in 1.6 s, 3/3.
Neither --no-concurrent-sparkplug --no-maglev nor global.gc() right before process.exit() avoids the hang in this repro (3/3 each).
In the wild, a chain of ~210 Node processes plus node:test suites under load on a 10-core machine hits it in about 2 of 7 full runs. Stuck process, main thread: Environment::Exit → DefaultProcessExitHandlerInternal → DisposePlatform → NodePlatform::Shutdown → WorkerThreadsTaskRunner::Shutdown → uv_thread_join; worker: ConcurrentBaselineCompiler::JobDispatcher::Run → BaselineCompiler::Build → HeapAllocator::RetryCustomAllocateLight → CollectionBarrier::AwaitCollectionBackground.
No related entry in the v26.10.0 / v26.11.0 changelogs. A backport to v26.x would be much appreciated.

V8 background jobs, such as concurrent Sparkplug and Maglev compiles, can run into the heap limit. They then post a GC request to the main thread and park in CollectionBarrier::AwaitCollectionBackground() until the main thread collects garbage or the isolate is torn down. process.exit() does neither. DefaultProcessExitHandlerInternal() calls DisposePlatform() while the isolate is still alive and not running JS, and NodePlatform::Shutdown() joins the worker threads. A worker that is parked at that point never wakes up, and the join hangs forever. Pass the exiting isolate down to NodePlatform::Shutdown(). While the workers finish their current tasks, the main thread checks every 10ms whether a foreground task was posted for that isolate. If so, it drops the queued tasks, which would never run on this path, and performs a GC so that the parked workers can finish. Normal exits dispose the isolate before the platform and are not affected. Fixes: nodejs#64274 Signed-off-by: Manzoor Wani <manzoorwani.jk@gmail.com>

aduh95

The added test seems to be flaky on main (i.e. without the fix), maybe it's related to the new V8 version. Here's the result of tools/test.py -t 20 --repeat=99 test/parallel/test-process-exit-background-gc.js on my machine

# Without my suggestion
[02:11|% 100|+  64|-  35]: Done  

# With my suggestion
[03:05|% 100|+  54|-  45]: Done

The test only hung on an unfixed build about a third of the time, because the window in which the main thread is out of JS depended on how fast the machine runs pbkdf2, and the stress allocation task had to run into the heap limit inside that window. Calibrate the iteration count from a short probe so that the window is about a second everywhere, and use up the old generation budget just before exiting so that the next background allocation fails and parks the task. Run in the test process instead of spawning a child, which also drops the child process overhead. On an unfixed build the test now hangs in 20 of 20 runs, and it passes 30 of 30 with the fix. Signed-off-by: Manzoor Wani <manzoorwani.jk@gmail.com>

manzoorwanijk · 2026-10-09T08:17:42Z

@aduh95 Thanks, you are right. The window where the main thread is out of JS depended on how fast the machine runs pbkdf2, and the stress allocation task had to run into the heap limit inside that window, so whether it hung was luck.

Reworked in e7f8e56, taking your suggestions: no child process, body at top level, flags via the // Flags: comment. Two things on top of that, because the suggestions alone left it at a coin flip: the iteration count is now calibrated from a short probe so the window is about a second on any machine, and the old generation budget is used up right before exiting so the next background allocation fails and parks the task.

On an unfixed build it now hangs in 20 of 20 runs here, and passes 30 of 30 with the fix. Could you re-run your --repeat=99 loop?

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs involving general changes in the lib/ or src/ directories. needs-ci PRs that need a full CI run. labels Sep 21, 2026

manzoorwanijk marked this pull request as ready for review September 21, 2026 10:02

manzoorwanijk mentioned this pull request Sep 21, 2026

v8: avoid V8 worker hang during platform shutdown #64283

Closed

manzoorwanijk mentioned this pull request Sep 21, 2026

Build/Test Tools: Stop builds hanging on Node.js 24 shutdown WordPress/wordpress-develop#13608

Closed

jasnell requested review from addaleax and joyeecheung September 21, 2026 11:39

manzoorwanijk force-pushed the fix/platform-shutdown-hang branch from 8da904b to 8816d66 Compare September 29, 2026 06:40

henkisdabro mentioned this pull request Oct 2, 2026

signals test: SIGINT fixture still running after 15 s on macOS CI henkisdabro/sandcastle-kit#164

Closed

4 tasks

This was referenced Oct 2, 2026

fix(test): CLI JSON e2e cases time out when the built CLI deadlocks in process.exit on loaded hosts openclaw/openclaw#163630

Merged

fix: CLI and Gateway processes can hang forever at exit on Node 24 and 26 openclaw/openclaw#163788

Merged

henkisdabro mentioned this pull request Oct 3, 2026

Tests that spawn the CLI can hang forever on Node 24's exit deadlock henkisdabro/sandcastle-kit#226

Closed

MikeMcC399 added the review wanted PRs that need review. label Oct 5, 2026

meinharrd mentioned this pull request Oct 6, 2026

fix(ci): remove process.exit() from the macOS Ant download step, add a hang watchdog (#544) solardev-xyz/freedom-browser#574

Merged

manzoorwanijk force-pushed the fix/platform-shutdown-hang branch from 7511be4 to ed0841e Compare October 9, 2026 06:27

aduh95 reviewed Oct 9, 2026

View reviewed changes

Comment thread test/parallel/test-process-exit-background-gc.js Outdated

Comment thread test/parallel/test-process-exit-background-gc.js

Comment thread test/parallel/test-process-exit-background-gc.js Outdated

Comment thread test/parallel/test-process-exit-background-gc.js

manzoorwanijk requested a review from aduh95 October 9, 2026 09:36

Navigation Menu

Repository navigation

src: fix hang when joining workers in process.exit() - #66171

src: fix hang when joining workers in process.exit()#66171
manzoorwanijk wants to merge 2 commits into
nodejs:mainfrom
manzoorwanijk:fix/platform-shutdown-hang

manzoorwanijk commented Sep 21, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 21, 2026

Uh oh!

manzoorwanijk commented Sep 21, 2026 •

edited

Loading

Uh oh!

codecov Bot commented Sep 21, 2026 •

edited

Loading

Uh oh!

manzoorwanijk commented Oct 3, 2026

Uh oh!

MikeMcC399 commented Oct 5, 2026

Uh oh!

manzoorwanijk commented Oct 5, 2026

Uh oh!

PetrKrcek commented Oct 7, 2026

Uh oh!

aduh95 left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

manzoorwanijk commented Oct 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

manzoorwanijk commented Sep 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Sep 21, 2026

Uh oh!

manzoorwanijk commented Sep 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov Bot commented Sep 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

manzoorwanijk commented Oct 3, 2026

Uh oh!

MikeMcC399 commented Oct 5, 2026

Uh oh!

manzoorwanijk commented Oct 5, 2026

Uh oh!

PetrKrcek commented Oct 7, 2026

Uh oh!

aduh95 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

manzoorwanijk commented Oct 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

manzoorwanijk commented Sep 21, 2026 •

edited

Loading

manzoorwanijk commented Sep 21, 2026 •

edited

Loading

codecov Bot commented Sep 21, 2026 •

edited

Loading