[Bug]: V8 fatal 'jit_page_->allocations_' crash in sandbox tests on Windows Node 24 CI

[jimhoyd]

Runtime revision and environment

main @ 94d8429 (release: v0.6.1), GitHub Actions windows-latest, Node 24, ci / verify (windows-latest, 24, 1) in Publish release run 36078611503.

Minimal reproduction

Not reproducible on demand. test/sandbox.test.ts aborted the Node process mid-file:

# Fatal error in , line 0
# Check failed: jit_page_->allocations_.erase(addr) == 1.
 2: V8_Fatal
 3: v8::internal::ThreadIsolation::UnregisterJitAllocationForTesting

Expected: the sandbox tests pass (they did on Windows Node 22 and 26 and on every Linux/macOS job in the same run). Actual: V8 hard-crashes the test process, which fails the release's CI gate before publish.

Relevant output

A V8 internal assertion in JIT page bookkeeping, not a URLCode assertion. It appears to be a Node 24 / V8 bug on Windows, triggered by the sandbox's QuickJS/WASM worker churn. Unverified: whether it recurs, and whether an upstream Node issue already exists. The failed job was re-run to complete v0.6.1.

Options: find/track the upstream Node issue; retry the sandbox test file once on this specific fatal signature in CI; or pin the Windows Node 24 leg to a patched Node release once one exists. Do not weaken the sandbox tests themselves.

[jimhoyd]

Related observation, different signature, recorded so it is not lost: during the extension architecture refactor, one npm run verify run in packages/auth crashed a worker with a V8 fatal error (Check failed: !is_null() in Builtin_CallAsyncModuleFulfilled, Node 26.8.2, macOS) in test/auth-core.test.ts, right after the 'configuration revision chains' test, apparently while the auth store's worker thread was being terminated. It did not reproduce in 12 isolated runs of that file or in 5 later full runs. Unverified whether this shares a cause with the Windows sandbox crash here.

[jimhoyd]

Recurred once more (second sighting): same V8_Fatal … Builtin_CallAsyncModuleFulfilled on Node 26.8.2 macOS, this time in packages/auth/test/recovery-drill.test.ts during a full npm run verify, again with no assertion failure; that file then passed 5 consecutive isolated runs and the next full verify passed. Still unverified whether it shares a cause with the Windows crash above.

[jimhoyd]

Investigation notes (no code changed). Where something is not verified, it says so.

Upstream

• Windows signature (jit_page_->allocations_.erase(addr) == 1 / ThreadIsolation): no upstream report or fix found; searches return only this issue. The nearest is Intermittent fatal CHECK in compiler/heap-refs on v24.x — request to backport V8 14.6's JSHeapBroker thread-safety fixes nodejs/node#66126 (open; V8 14.6 thread-safety backports for v24.x), which has a different signature. There is no Node 24.x release to pin to.
• macOS signature (!is_null() in Builtin_CallAsyncModuleFulfilled): this matches a known family of crashes where a worker is terminated during async module evaluation (top-level await):
  • Assertion failure when calling process.exit() from a Worker that has TLA nodejs/node#43182, fixed by V8 "[module] Fix aborts in terminated async module evaluation" (2022, Node 18).
  • Fatal error nullptr check in AsyncModuleExecutionFulfilled nodejs/node#53238 (Node 22, closed stale, no fix).
  • v23 regression: Crash when throwing error with imports and multiple TLAs nodejs/node#56854.
  • Nothing names Node 26.x.
  • In current V8 main, AsyncModuleExecutionFulfilled (src/objects/source-text-module.cc) still has ToHandleChecked() calls (≈1083/1133/1151), and that is exactly CHECK(!is_null()).

URLCode code with the matching race (verified that the pattern exists; not verified that it causes the crash)

• Config worker: packages/core/src/config-worker.ts:8 posts its result from inside a top-level await, and config.ts:18 also uses top-level await. loadDocument (config.ts:401–415) then terminate()s as soon as the message arrives, which is while the module's async evaluation, ending in CallAsyncModuleFulfilled, may still be settling. This happens on every config load, in tests and in production.
• Sandbox pool: function-worker.ts:12 compiles QuickJS WASM under a top-level await. In functions.ts, terminates happen on deadline (:191), init failure/timeout (:129), respawn (:167–177) and close() (:213). close() can terminate a respawn still inside getQuickJS(). test/sandbox.test.ts:93–117 drives 8 deadline terminates while respawns compile the same WASM module concurrently. This plausibly fits the Windows JIT-page race (speculative).
• Auth store worker: a (regex-based) scan found no top-level await in its import graph, so the "while the auth store worker was terminated" attribution is probably another thread. Candidates are the config worker and packages/auth/scripts/recovery-drill.mjs:79 (top-level await; closes two stores before it settles).

Options, ranked

1. Stop terminating workers during module evaluation. This is a robustness fix, not a test change. On success, let the config worker finish and exit and await 'exit' (or remove its top-level await), keeping terminate() for deadline and error paths. Make FunctionPool.close() await in-flight spawns. Guest-deadline terminates stay.
2. Gather evidence: capture the thread and native stack per sighting; stress-loop loadDocument and pool start/close on Node 26.8.2 macOS and deadline churn on Windows Node 24; file a minimal nodejs/node report if one reproduces.
3. Pin Node versions: not possible yet (no upstream fix).
4. CI retry on these exact signatures: a last resort and a policy decision; it would hide a crash that production paths can also hit.

---

Generated by Claude Code

[jimhoyd]

Recurred after #761's worker-teardown fix: identical signature (Check failed: jit_page_->allocations_.erase(addr) == 1, V8_Fatal → ThreadIsolation::UnregisterJitAllocationForTesting) in test/sandbox.test.ts on verify (windows-latest, 24, 2), release PR #799 (v0.6.4, head 6d61f0a3), run https://github.com/jimhoyd-com/urlcode/actions/runs/36268481263/job/108477798650. Every sandbox test in the file had passed (the last was 'runtime-constructed imports cannot read another route module outside the declared graph') before V8 aborted the process; the other 28 checks passed. So #761 did not remove the Windows Node 24 trigger; still no upstream fix found. Failed job re-run to unblock the release. Reopening so the remaining options (a minimal nodejs/node report, or the owner's call on a signature-scoped CI retry) are not lost.

---

Generated by Claude Code

[jimhoyd]

Confirmed recurrence during the full-matrix validation of PR #819 at 9e110600 (the change only touches packages/auth/test/headless-auth-profile-recipe.test.ts). Windows Node 24 core shard 3 failed in test/sandbox.test.ts with the same fatal signature:

Check failed: jit_page_->allocations_.erase(addr) == 1.
V8_Fatal
v8::internal::ThreadIsolation::UnregisterJitAllocationForTesting

Job: https://github.com/jimhoyd-com/urlcode/actions/runs/36333594243/job/108660125858

The immediately preceding reported test was runtime-constructed imports cannot read another route module outside the declared graph. This confirms recurrence, not a deterministic reproducer or an upstream cause. The original release run 36332281231 passed its core jobs and failed only Windows auth path handling; that auth fix remains separate. No sandbox code or checks have been changed or disabled.

[jimhoyd]

Decision (owner, 2026-09-27): reproduce and report upstream. There will be no crash-masking retry in CI, so the crash stays visible.

• A minimal standalone reproducer, plus a manually triggered Windows/Node 24 workflow to run it on demand.
• A drafted nodejs/node report, for the owner to review and file.

---

Generated by Claude Code

[jimhoyd]

Reopened: #827 closed this automatically, but the crash is not fixed. #827 added reproducers (scripts/repro/) and a manual workflow (.github/workflows/v8-jit-repro.yml, dispatch only). The next step is to run it on Windows and file the upstream nodejs/node report with the observed frequency:

gh workflow run v8-jit-repro.yml -f reproducer=all -f os='["windows-latest"]' -f node='["22","24","26"]' -f runs=10

---

Generated by Claude Code