Repository navigation
pglive: Bun 1.3.x panics (Segmentation fault at 0xFFFFFFFFFFFFFFF8) after queen-actors-pg-edges-live runs, failing the job #1813
Description
Part of #1729.
Tests / server-pglive on the escalation-fix PR #1811 (run 38099896355) failed with no test failure at all:
panic: Segmentation fault at address 0xFFFFFFFFFFFFFFF8
error: script "test:pglive" exited with code 1
The lane that wrote #1811 reproduced it locally. Bun 1.3.11 panicked in 3 of 20 runs of tests/pglive/queen-actors-pg-edges-live.test.ts, at about 43 s, after all 10 tests had run. The unmodified file from queen crashed the same way in 2 of 20 runs. So this is a Bun runtime crash at teardown, not a test or runtime defect of ours.
What to do
- Pin it down: run the file alone with
--timeoutandBUN_DEBUG, and see whether a still-openpgpool or socket at exit triggers it. - Close every pool and client in
afterAllif one is left open. - If it is a Bun bug, file it upstream with the minimal repro and try the current Bun.
- Until then, a crash after all tests have passed must stay distinguishable from a test failure in CI. Do not hide it.
Acceptance: 20 consecutive runs of the file without a panic.
Activity
Merge pull request #1837 from gHashTag/fix-1813-pglive-bun-panic
gHashTag commentedon Oct 11, 2026
Fixed by #1837, merged into
queenas f1b59b2. The cause was terminating the PgLink beat Worker while its modules were still compiling, which segfaults Bun 1.3.6/1.3.11. Stop now waits for the worker'sloadedmessage (or its load error) before it terminates. The whole pglive suite passed 20 consecutive runs.Closesfires only onmain, so this is closed by hand. The same exposure inthreadWorkis #1865.fix(queen): a beat thread is ended only once it has loaded, so a node…
fix(queen): a thread turn's worker is ended only once it has loaded, …