Skip to content

Windows Crash (Bun Segfault)

The runner starts, connects to the relay, registers successfully, then crashes:

2026-07-09T14:00:00.000Z [daemon] connecting to relay at https://example.com/runner…
2026-07-09T14:00:00.000Z [daemon] connected. Registering as 9c0174ad-…
2026-07-09T14:00:00.000Z [daemon] registered as 9c0174ad-…
panic(thread 41472): Segmentation fault at address 0x3C
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

The crash address varies — common values include 0x3C, 0x18, 0x0, 0x30, and 0xFFFFFFFFFFFFFFFF. The crash may happen on a worker thread (not the main thread). It is non-deterministic — sometimes the runner works fine for hours, other times it crashes within seconds.


The crash is caused by a JavaScriptCore (JSC) garbage collector use-after-free bug in Bun’s Windows builds. Specifically:

  • Object finalizers fail to clear WriteBarrier fields before destroying objects
  • The GC then accesses freed memory during sweep/marking phases
  • This causes a segmentation fault at a small offset from a null/freed pointer

Three distinct crash families have been identified:

FamilyThreadAddressesTrigger
Worker Thread CleanupNon-main0x3C, 0x18, 0x108Worker/thread shutdown races
GC Sweep FinalizerMain or worker0x0, 0x4, 0x30ShellInterpreter finalizer bug
Heap CorruptionMain0xFFFFFFFFFFFFFFFFDouble-free during Worker/VM destruction

The runner daemon hits multiple known triggers:

  • Long-lived process — runs continuously
  • child_process.spawn() — spawns worker subprocesses for each session
  • WebSocket threads — Socket.IO background I/O
  • fetch() calls — usage cache refresh on a recurring timer (main-thread async I/O)
  • Compiled standalone binarybun build --compile binaries are more affected than bun run

Every tested Bun version on Windows crashes through at least v1.3.10. The list below was last verified in early 2026:

v1.2.18, v1.2.21, v1.3.0, v1.3.5, v1.3.6, v1.3.8, v1.3.9-canary, and v1.3.10.


The bug is Windows-specific. Running the runner inside WSL2 avoids it entirely:

Terminal window
wsl
Terminal window
# Inside WSL2:
pizza runner

Compiled standalone executables crash more frequently than bun run. If you have Bun installed on Windows, you can run from source:

Terminal window
# Install Bun for Windows
powershell -c "irm bun.sh/install.ps1 | iex"
# Clone and run from source
git clone https://github.com/Pizzaface/PizzaPi.git
cd PizzaPi
bun install
bun run build
bun packages/cli/src/index.ts runner

The crash is a race condition — non-deterministic. Simply restarting often works:

Terminal window
pizza runner

The supervisor process automatically restarts the daemon on crash, so the runner may recover on its own.

If a .env file exists in the runner’s working directory, try removing or renaming it as a test. Bun loads .env files automatically and, anecdotally, some standalone executables have crashed when one is present.

If you have access to a Linux or macOS machine (including a cloud VM), run the runner there instead. The crash is Windows-specific.


This is tracked across multiple GitHub issues:

IssueDescription
#18198Original worker thread segfault after exit
#23177ShellInterpreter finalizer GC use-after-free (root cause identified)
#23470Crash during bun build --compile
#23904Compiled exe crash at 0xFFFFFFFFFFFFFFFF
#26026Bun v1.3.5 segfault on Windows 10 x64
#26625GC finalizer crash persists in v1.3.8
#26853Segfault 0xFFFFFFFFFFFFFFFF on Windows x64 canary
#27414Bun v1.3.10 still crashing on Windows (Feb 2026)

Embedder Reports (Other Projects Experiencing Same Bug)

Section titled “Embedder Reports (Other Projects Experiencing Same Bug)”
IssueDescription
claude-code#2187578 crashes documented, 3 crash families catalogued
claude-code#27003Confirms v1.3.10 fix is incomplete

The Bun team is aware of the issue and has been shipping incremental fixes. The v1.3.10 release addressed several crash variants but the underlying JSC GC use-after-free on Windows is not fully resolved. We will ship a new compiled binary built with a fixed Bun version when a complete fix ships.

In the meantime, WSL2 is the recommended way to run PizzaPi on a Windows machine.