Repository navigation
Windows: Bun 1.3.14 segfaults in long-running localhost HTTP proxy #32585
Description
What happened?
On Windows 11, bun run src/cli.ts start for a local opencodex development proxy can crash after the HTTP server has been running for a while. The process is serving a localhost proxy/dashboard and uses Bun's fetch/http_server paths.
The crash is not a clean JavaScript exception. Bun prints a native crash report and exits with a segmentation fault.
I have seen this more than once on Bun 1.3.14. As a local workaround, I switched the watchdog to prefer a canary Bun binary (C:\Users\cherr\.bun-canary\bin\bun.exe, currently reporting 1.4.0), and the same proxy has stayed up under that runtime so far.
Command
bun run src/cli.ts startIn the crashing runs the executable path was:
C:\Users\cherr\.bun\bin\bun.exe
Crash excerpts
Short run:
Args: "C:\Users\cherr\.bun\bin\bun.exe" "run" "src/cli.ts" "start"
Features: abort_signal(5) fetch(6) http_server jsc transpiler_cache(2) tsconfig
Elapsed: 61275ms | User: 1453ms | Sys: 765ms
RSS: 114.54MB | Peak: 0.15GB | Commit: 0.37GB | Faults: 54893 | Machine: 33.65GB
panic(main thread): Segmentation fault at address 0xFFFFFFFFFFFFFFFF
oh no: Bun has crashed. This indicates a bug in Bun, not your code.
https://bun.report/1.3.14/wr10d9b296gDghooCguy6xDyg3+B8pv+Bqiu+B___A2DD
Longer run with high peak memory reported:
Args: "C:\Users\cherr\.bun\bin\bun.exe" "run" "src/cli.ts" "start"
Features: Bun.stdin(2) Bun.stdout(2) abort_signal(7) fetch(10) http_server jsc transpiler_cache(2) tsconfig
Elapsed: 291839ms | User: 30687ms | Sys: 31796ms
RSS: 0.15GB | Peak: 12.13GB | Commit: 0.47GB | Faults: 11397952 | Machine: 33.65GB
panic(main thread): Segmentation fault at address 0xFFFFFFFFFFFFFFFF
oh no: Bun has crashed. This indicates a bug in Bun, not your code.
https://bun.report/1.3.14/wr10d9b296gDshooCguy6xDyg3+B8pv+Bqiu+B___A2DD
Environment
Bun stable: 1.3.14
Bun canary workaround: 1.4.0
OS: Microsoft Windows 11 Pro 10.0.26200, x64
CPU flags shown by crash report: sse42 avx avx2
Project command: opencodex local dev proxy, `bun run src/cli.ts start`
Notes
- The crash appears after the proxy has been running, not immediately at startup.
- The app is a long-running localhost HTTP proxy/dashboard process.
- There are repeated
DOMException TimeoutErrorlogs nearby from outbound request timeouts, but the terminal failure is Bun's native segmentation fault. - I do not have a minimal reproduction yet; filing because the crash report itself asks for an issue and because the canary runtime appears to avoid the failure in this local setup.
Activity
robobun commentedon Jun 22, 2026
✅ Reproduced the leak this comes from. A
node:netsocket whose readable side is paused (backpressure) and whose peer then disconnects never emits acloseevent: its fd/handle is never released and the event loop never idles. In a long-running proxy that grows memory and OS handles without bound, and on Windows the handle exhaustion faults atINVALID_HANDLE_VALUE(the0xFFFFFFFFFFFFFFFFaddress in both of your crash reports).The fix is already open in #31654 (awaiting review). You are already on 1.4.0 via the canary workaround, which avoids the crash for your setup, so staying there is the right call until #31654 lands.