The silent CI e2e wedges (three runs: 32413971653, 32440437223, 32442122042, plus two more crashes in 32442712490) are all one bug, now fully characterized by the harness diagnostics on #55's branch.
Signature
~600ms after [boot] wire: alice ⇄ bob over the relay…, the renderer takes:
Received signal 11 SEGV_ACCERR 083000660c94 (run 32442122042)
Received signal 11 SEGV_ACCERR 1d1800660c94 (run 32442712490, petname-ceremony)
Received signal 11 SEGV_ACCERR 1c6000660c94 (run 32442712490, credential-flow)
The low bits are identical across ASLR bases: 00660c94. Same offset into the same kind of large aligned reservation every time — a deterministic native fault, not corruption roulette. Consistent with a guard-page hit in a wasm-memory cage or a JSPI continuation stack; the wire step is peak JSPI suspension activity (iroh relay websocket + webcrypto sign, concurrent).
Why it presented as an hour of silence
The renderer hangs in its own crash handler instead of exiting — no crash event reaches Playwright, waitForFunction's in-page timeout dies with the page, browser.isConnected() stays true. Pre-diagnostics, that was a 56-minute hang until the job timeout; now it's a 240s labeled deadline + browser relaunch, and (since d21e2ea) a fast labeled failure when the crash event does arrive.
Memory exonerated
Continuous /proc sampling (5s cadence) across both crashes in run 32442712490: chrome tree flat (~630MB and ~335MB respectively), zero orphans, ~14.6GB MemAvailable, swap untouched. Not pressure.
Environment sensitivity
Relation to #49
Different failure class from #49's traps (user-create wit-bindgen null-state assert; Deno parked-thread assert) — this is a native renderer crash, not a wit-level trap — but the same neighborhood: JSPI + concurrent async host imports during engine wire-up. Worth checking deltic's JSPI stack sizing / suspension paths first; if it reproduces under a plain v8/chromium JSPI harness it goes upstream.
Next steps
The silent CI e2e wedges (three runs: 32413971653, 32440437223, 32442122042, plus two more crashes in 32442712490) are all one bug, now fully characterized by the harness diagnostics on #55's branch.
Signature
~600ms after
[boot] wire: alice ⇄ bob over the relay…, the renderer takes:The low bits are identical across ASLR bases:
00660c94. Same offset into the same kind of large aligned reservation every time — a deterministic native fault, not corruption roulette. Consistent with a guard-page hit in a wasm-memory cage or a JSPI continuation stack; the wire step is peak JSPI suspension activity (iroh relay websocket + webcrypto sign, concurrent).Why it presented as an hour of silence
The renderer hangs in its own crash handler instead of exiting — no crash event reaches Playwright,
waitForFunction's in-page timeout dies with the page,browser.isConnected()stays true. Pre-diagnostics, that was a 56-minute hang until the job timeout; now it's a 240s labeled deadline + browser relaunch, and (since d21e2ea) a fast labeled failure when the crash event does arrive.Memory exonerated
Continuous /proc sampling (5s cadence) across both crashes in run 32442712490: chrome tree flat (~630MB and ~335MB respectively), zero orphans, ~14.6GB MemAvailable, swap untouched. Not pressure.
Environment sensitivity
--no-sandbox --disable-dev-shm-usage.Relation to #49
Different failure class from #49's traps (
user-createwit-bindgen null-state assert; Deno parked-thread assert) — this is a native renderer crash, not a wit-level trap — but the same neighborhood: JSPI + concurrent async host imports during engine wire-up. Worth checking deltic's JSPI stack sizing / suspension paths first; if it reproduces under a plain v8/chromium JSPI harness it goes upstream.Next steps
taskset -c 0,1+ full suite in a loop) to get a local debugger on it00660c94against the wasm module layout / v8 reservation shapes