Bun Segmentation Fault after heavy use w/ long runtime and memory usage #27715
Description
What version of Bun is running?
============================================================ Bun v1.3.10 (1423d3c8) Windows x64 (baseline) Windows v.win10_cu CPU: sse42 avx avx2 Args: "C:\Users\TheFox_ReDux.local\bin\claude.exe" Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(9213) fetch(86637) http_server jsc spawn(10382) standalone_executable process_dlopen(3) Builtins: "bun:main" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:constants" "node:crypto" "node:events" "node:fs" "node:fs/promises" "node:http" "node:https" "node:module" "node:net" "node:os" "node:path" "node:path/posix" "node:path/win32" "node:perf_hooks" "node:process" "node:stream" "node:timers/promises" "node:tls" "node:tty" "node:url" "node:util" "node:zlib" "node:worker_threads" "undici" "ws" Elapsed: 674675537ms | User: 137978890ms | Sys: 2023500ms RSS: 2.19GB | Peak: 8.55GB | Commit: 0.07TB | Faults: 521007421 | Machine: 34.28GB panic(main thread): Segmentation fault at address 0x18 oh no: Bun has crashed. This indicates a bug in Bun, not your code.
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What steps can reproduce the bug?
No code, Claude Code was running a bash script to compile a build. This is Claud's annalysis: ●
That's a gnarly one. Some notable numbers from the crash:
- Elapsed: ~7.8 days of session uptime (674M ms)
- Peak RSS: 8.55 GB — that's a lot of memory pressure - 521M page faults — the process was thrashing hard
- Commit: 0.07 TB — virtual memory was wildly overcommitted
The segfault at address 0x18 (near-null dereference) is classic memory corruption / use-after-free territory. Looks like Bun's GC or JIT
got into a bad state after running for a week under heavy memory pressure. This is a Bun bug, not anything in your code or from the tsc
run.
What is the expected behavior?
No response
What do you see instead?
No response
Additional information
No response