René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Concurrent PGlite WebAssembly initialization intermittently SIGSEGVs Node.js","articleBody":"### Version\n\nv26.5.0 (also reproduced on Node 22, 24, 25)\n\n### Platform\n\n```text\nThe primary Docker reproduction ran on this host:\n\n\nLinux dragon-pro18 6.18.35-1-cachyos-lts #1 SMP PREEMPT_DYNAMIC Sat, 13 Jun 2026 12:39:40 +0000 x86_64 GNU/Linux\nIntel Core Ultra 9 285HX, 24 cores online\n\n\nDocker replaces the userspace and Node installation but shares the host kernel and CPU. The same failure occurs with the host Node binary.\n```\n\n### Subsystem\n\nV8 / WebAssembly (observed through `child_process`)\n\n### What steps will reproduce the bug?\n\nThe minimal repository is:\n\nhttps://github.com/gadicc/node-pglite-wasm-sigsegv-repro\n\nIt has one runtime dependency, `@electric-sql/pglite@0.5.4`. PGlite ships its PostgreSQL engine as WebAssembly; there is no native addon.\n\nOn a machine with at least 20 GiB available:\n\n```sh\ngit clone https://github.com/gadicc/node-pglite-wasm-sigsegv-repro.git\ncd node-pglite-wasm-sigsegv-repro\ndocker build -t pglite-node-sigsegv-repro .\ndocker run --rm pglite-node-sigsegv-repro\n```\n\nEquivalently, with a local Node installation:\n\n```sh\nnpm ci\nnpm run repro\n```\n\nEach of 16 child processes independently creates an in-memory PGlite client, runs `SELECT 1`, awaits `client.close()` in `finally`, and exits. The parent repeats that wave up to 50 times and stops on the first failure. There is no Vitest, Vite, test runner, application code, native addon, IPC dependency, or database persistence.\n\nThe memory warning matters: the observed cgroup peak was approximately 19 GiB. The recorded failing run had `oom=0` and `oom_kill=0`.\n\n### How often does it reproduce? Is there a required condition?\n\nIt is intermittent and requires concurrent processes in the measured setup.\n\nTwo clean Node 26 official-image runs failed at waves 13 and 8. Other results\nwithout V8 CLI overrides were:\n\n| Node | Result |\n| --- | --- |\n| 25 | 1/20 waves failed |\n| 24 | 4/45 waves failed |\n| 22 | 1/10 waves failed |\n| 20 | 0/40 waves failed |\n\nThe Node 20 result is a non-reproduction in an intermittent test, not evidence that it is unaffected. Official Node 20, 22, 24, and 26 images expose the same relevant defaults: Liftoff, lazy compilation, dynamic tiering, and WASM tier-up are enabled, with up to 128 compilation tasks. Node 20 did reproduce with `--no-liftoff`, which forces the optimizing compiler.\n\nThe Node 27 V8 canary failed at wave 17 with `child_process.fork()` and failed 2/50 waves with ordinary `child_process.spawn()`. A sequential one-child control passed 50/50 waves.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nEvery child should complete the query, close the PGlite client, and exit with code 0.\n\n### What do you see instead?\n\nAn intermittent child is terminated by `SIGSEGV`:\n\n```text\nnode=v26.5.0 v8=14.6.202.34-node.24 platform=linux arch=x64 children=16 waves=50\nwave=1 passed=16/16\n...\nwave=8 passed=15/16\nchild=10 code=null signal=SIGSEGV elapsedMs=4315\nfailedWaves=1 completedWaves=8 requestedWaves=50\n```\n\n\n### Additional information\n\nNative diagnostics from a sanitized-environment reproduction:\n\n1. `strace` recorded an initial `SIGSEGV` with `SEGV_MAPERR` at a large guarded WASM address.\n2. Node's `node::TrapWebAssemblyOrContinue` called `raise(SIGSEGV)` after V8 declined to handle the address as a valid WASM trap.\n3. The retained core records the resulting `SI_TKILL` signal.\n4. GDB placed another crash in the lazy WASM compilation path through `LiftoffAssembler::PrepareCall`, `ExecuteLiftoffCompilation`, `CompileLazy`, and `Runtime_WasmCompileLazy`, with background Turboshaft compilation active.  A separate retained crash was in `v8::internal::MarkingBarrier::MarkValueLocal`.\n\nRelevant flag controls on Node 25:\n\n- default: reproduced;\n- `--wasm-enforce-bounds-checks`: reproduced;\n- `--wasm-num-compilation-tasks=1`: reproduced;\n- `--no-wasm-tier-up`: passed 100/100 waves in that version;\n- `--no-liftoff`: reproduced.\n\nThe Node 27 canary nevertheless reproduced with both `--no-wasm-tier-up` and `--liftoff-only`, so no single WASM tier is universally required.\n\nI also built the exact PGlite 0.5.4 tag using its official `pnpm build:all:debug` workflow. That PostgreSQL WASM used `-g`,\n`-gsource-map`, and `--no-wasm-opt`; LLVM verified 1,322 DWARF compilation units without errors. With Node 25.2.1, a sequential control passed 5/5 waves and eight concurrent children passed 5/5 waves, while 16 concurrent children\nreproduced `SIGSEGV` in wave 2. The cgroup peak was 67,306,729,472 bytes (62.7 GiB), with `oom=0` and `oom_kill=0`.\n\nRuntime controls using the same PGlite version and concurrency:\n\n- Bun 1.3.11 / JavaScriptCore: 50/50 waves passed;\n- Deno 2.8.0 / V8 14.9.207.2, default: 50/50 passed;\n- Deno 2.8.0 / V8 14.9.207.2, `--no-liftoff`: 50/50 passed.\n\nThe evidence therefore establishes a Node-runtime-specific interaction in the tested configurations, but does not yet distinguish Node's WASM trap/embedding layer or build configuration from a V8 defect exposed by Node. `d8` is V8's standalone JavaScript shell; reproducing there without Node or its APIs would prove that the bug exists independently in V8. I would appreciate guidance on whether this should be routed or cross-filed to V8.\n\nOn 2026-07-14 I searched open Node and V8 reports for PGlite, `TrapWebAssemblyOrContinue`, `WasmCompileLazy`, `LiftoffAssembler`, and concurrent WASM `SIGSEGV`s, and found no exact duplicate. The reproduction README records the related but materially different reports.\n\nLastly,\n\n- Co-authored with Codex gpt-5.6-sol, reasoning: high, with significant human input.\n- This issue was opened by me personally by hand and without any automation.\n\nEdit 1: Added PGLite debug build info in \"Additional Information\" above.","author":{"url":"https://github.com/gadicc","@type":"Person","name":"gadicc"},"datePublished":"2026-07-14T13:24:22Z","url":"https://github.com/nodejs/node/issues/64500"}