[BUG]: Concurrent Node processes initializing PGlite can SIGSEGV the Node runtime

[gadicc]

Describe the bug

When multiple independent Node processes initialize PGlite concurrently, an intermittent process receives a native SIGSEGV. This is reproducible without Vitest, Vite, application code, persistence, or a native addon, and still occurs when every PGlite client is explicitly closed in finally.

The current evidence suggests a Node/V8 WebAssembly-runtime interaction rather than a JavaScript exception in PGlite. I am reporting it here as well because PGlite's PostgreSQL WASM workload is the reliable trigger and PGlite maintainers may recognize a compilation or generated-WASM pattern that can help reduce or route it.

Node issue: nodejs/node#64500

Minimal repository: https://github.com/gadicc/node-pglite-wasm-sigsegv-repro

To Reproduce - include code sample(s)

Use a Linux x64 machine with at least 20 GiB available. Sixteen simultaneous clients reached an observed cgroup peak of approximately 19 GiB.

git clone https://github.com/gadicc/node-pglite-wasm-sigsegv-repro.git
cd node-pglite-wasm-sigsegv-repro
docker build -t pglite-node-sigsegv-repro .
docker run --rm pglite-node-sigsegv-repro

The Dockerfile uses the official node:26-bookworm image and the checked-in npm lockfile. Each wave launches 16 independent processes. Each child does only:

import { PGlite } from "@electric-sql/pglite";

const client = new PGlite();

try {
  await client.query("SELECT 1");
} finally {
  await client.close();
}

Two clean official-image runs failed at waves 13 and 8. The sequential control using the same workload passed 50/50 waves.

Logs

node=v26.5.0 v8=14.6.202.34-node.24 platform=linux arch=x64 children=16 waves=50
wave=1 passed=16/16
...
wave=8 passed=15/16
child=10 code=null signal=SIGSEGV elapsedMs=4315
failedWaves=1 completedWaves=8 requestedWaves=50

The failing cgroup recorded oom=0 and oom_kill=0.

Native inspection found an initial SEGV_MAPERR at a guarded WASM address. Node's node::TrapWebAssemblyOrContinue then re-raised SIGSEGV after V8 did not classify the address as a valid WASM trap. Other retained crashes entered V8 lazy WASM compilation (LiftoffAssembler::PrepareCall / Runtime_WasmCompileLazy) and v8::internal::MarkingBarrier::MarkValueLocal. Raw cores are not public because process memory can contain environment values.

Details

• PGlite: 0.5.4
• Extensions: none
• OS: official Debian Bookworm Node image on Linux x64
• Node: v26.5.0, V8 14.6.202.34-node.24
• Also reproduced on Node 22, 24, 25, and a Node 27 V8 canary
• Bun 1.3.11 / JavaScriptCore control: 50/50 waves passed
• Deno 2.8.0 / V8 14.9.207.2 control: 50/50 waves passed

Forced optimizer experiments also reproduced with PGlite 0.3.15 and 0.4.1, so the underlying native crash does not appear to have been introduced by 0.5.4. This reproducer pins 0.5.4 because it triggers the failure reliably enough to investigate.

Additional context

I built the exact PGlite 0.5.4 tag (source commit 25d0a55e1f1e4c59f26d9e125150dda88a33fd00) using the documented
pnpm build:all:debug workflow. The PostgreSQL WASM build used -g, -gsource-map, and --no-wasm-opt. Its 50,321,851-byte pglite.wasm contained 1,322 DWARF compilation units and passed LLVM's DWARF verifier.

Using Node 25.2.1, a sequential control passed 5/5 waves and eight concurrent children passed 5/5 waves. With 16 concurrent children, wave 1 passed and child 9 received SIGSEGV in wave 2. After resetting the test scope's cgroup peak counter, that run peaked at 67,306,729,472 bytes (62.7 GiB), with oom=0 and oom_kill=0.

The debug build therefore retains the concurrency-dependent native crash. The remaining practical difficulty is attaching a DWARF-aware debugger to the unpredictable one of 16 independent Node children that fails. Guidance on the preferred capture workflow for that case would be useful.

Other

• Co-authored with Codex gpt-5.6-sol, reasoning: high, with significant human input.
• This issue was opened by me personally by hand and without any automation.

[gadicc]

Investigation update: root cause appears to be platform-level (hardware), not PGlite. I am closing this issue.

Following up on the linked Node issue (nodejs/node#64500) with a day of native debugging. Multiple crash captures on the affected machine show the kernel-reported fault address equal to the intended memory address with a single high bit set (2^42), while the intended address was validly mapped and the fault-time registers are clean — a pattern no software can produce. Deno (also V8) crashes under the same harness with a flipped high bit too, and a second machine (different CPU) runs 100/100 waves = 1,600 child-runs clean. The affected machine's journal shows unrelated applications crashing with anomalous fault addresses over the same period.

Conclusion: sporadic address-path corruption on this specific machine (Core Ultra 9 285HX) under heavy concurrent load; PGlite's large WASM module initializing in 16 concurrent processes is an excellent trigger but not the cause. Nothing for PGlite to fix, so I am closing this. The repro repository README documents the full investigation. I will report back on the Node issue once a stock-BIOS/firmware retest is done. Thanks for the time.

[rainder]

Additional signature for this issue, from a single-process setup (details in nodejs/node#64500 — comment cross-posted there):

Fatal error in ../../deps/v8/src/heap/code-range.cc
Check failed: jit_page_->allocations_.erase(addr) == 1

Node 24.18.0, pglite 0.5.4 (in-memory), Linux x64 CI container. One Node process running a node:test suite that creates/closes many in-memory PGlite instances sequentially — no concurrent child processes involved. Intermittent (~5% of CI runs); instance count alone is not the trigger (crashed in a file creating only 8 instances, while 300 minimal create/close cycles on the same hardware never crashed).

Same trigger class as this issue (PGlite WASM instantiate/free churn) and same V8 subsystem (ThreadIsolation / JIT page allocation tracking), but the abort is a deterministic V8 CHECK failure rather than a SIGSEGV — possibly a more debuggable manifestation of the same underlying registry desync.

[gadicc]

Re-opening for now due to common interest. The heavy debugging is happening in the node issue linked above.