Claude Code Segmentation fault
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Claude Code crashes deterministically on every invocation with an embedded Bun v1.3.14 segfault, before any UI renders or any session work begins. The crash occurs even on claude --help and claude doctor, which do no session/network/TUI work — so this is a startup-time runtime crash, not anything in application logic.
Environment is an Ubuntu 24.04.4 guest running in VirtualBox on an Intel 12th-gen (Alder Lake) host, kernel 6.17.0-23-generic.
claude --version is the only command that succeeds, because it prints and exits before the faulting initialization path runs.
Every crash has the same fingerprint:
panic(main thread): Segmentation fault at address 0x7FFF........FF8
Bun v1.3.14 (521eedd6) Linux x64 (baseline)
Illegal instruction (core dumped)
The faulting address is always near the top of the stack (...FF8) and the crash happens in ~160–190ms.
This is NOT the same bug as #57853
#57853 is a mid-session crash in JSC's parallel GC (SlotVisitor::drain, address 0xD0) that occurs 2–10 minutes into a session on worker threads. This bug is different:
- It is a startup crash (~160ms), reproducible on
claude --help. - The GC marker / Bun pool worker threads are parked in
futex_waitat the time of the crash — the fault is on the main thread during JSC call-frame setup, not in GC. - Setting
BUN_JSC_numberOfGCMarkers=1does not affect it.
Root cause (gdb analysis)
Caught under gdb, the fault is at 0x3f4cfb6 in a JSC call-frame stack-zeroing loop that overruns the stack guard page:
mov 0x10(%rbp),%rsi ; load CodeBlock/frame descriptor
mov 0x14(%rsi),%eax ; frame size (slots)
shl $0x3,%rax ; slots -> bytes
neg %rax
add %rbp,%rax ; target rsp = rbp - frameSize
mov %rsp,%rdx
mov %rax,%rsp
0x3f4cfad: cmp %rdx,%rsp ; loop
je 0x3f4cfbf
sub $0x8,%rdx
=> 0x3f4cfb6: movq $0x0,(%rdx) ; FAULT: zero-fill slot, %rdx walks past guard page
jmp 0x3f4cfad
r14 = 0xfffe000000000000 / r15 = 0xfffe000000000002 confirm JSC NaN-box frame setup. At the fault, rbp == rsp == 0x7ffffffdea30 (frame just entered) and rdx is decrementing 8 bytes at a time toward an unmapped page. The frame size being allocated overruns the stack — i.e. JSC computes a bad frame size or its stack-limit check is wrong, and the zero-fill loop overflows.
Things tested that do NOT fix it
BUN_JSC_numberOfGCMarkers=1BUN_JSC_useConcurrentGC=0BUN_JSC_useJIT=0(changes the LLInt vs JIT frame pattern but not the outcome)BUN_JSC_useConcurrentJIT=0ulimit -sat 8192, 16384, and unlimited (8192/16384 → same segfault; unlimited → OOMKilled)- Reinstalling; pinning older versions (2.1.118) — all ship the identical baseline Bun binary
The strongest correlating variable across this and the related reports (#57853, and the stale #27497) is kernel 6.17.0. Notably, this report is on an Intel i5-12450H (Alder Lake) while #57853 is on an AMD Ryzen 5 5500 — different CPU vendors, same kernel, same crash class — which points at the kernel (and the Bun 1.3.14 baseline binary) rather than the CPU.
What Should Happen?
claude --help, claude --version, claude doctor, and an interactive session should all launch without a Bun segfault on Ubuntu 24.04 / kernel 6.17.0 (incl. inside a VirtualBox guest on an Intel Alder Lake host). JSC should compute a valid call-frame size and not overrun the stack guard page during startup.
Error Messages/Logs
============================================================
Bun v1.3.14 (521eedd6) Linux x64 (baseline)
Linux Kernel v6.17.0 | glibc v2.39
CPU: sse42 popcnt avx avx2 (Intel i5-12450H, VirtualBox guest)
Args: "claude" "--help"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) jsc standalone_executable claude_code
Elapsed: 156ms | User: 144ms | Sys: 24ms
RSS: 42.80MB | Peak: 0.27GB | Commit: 42.80MB | Faults: 0 | Machine: 4.10GB
panic(main thread): Segmentation fault at address 0x7FFFA6FE7FF8
oh no: Bun has crashed. This indicates a bug in Bun, not your code.
Illegal instruction (core dumped)
gdb session (symbols not resolvable — JIT'd frames):
Thread 1 "2.1.148" received signal SIGSEGV, Segmentation fault.
0x0000000003f4cfb6 in ?? ()
(gdb) x/4i $pc
=> 0x3f4cfb6: movq $0x0,(%rdx)
0x3f4cfbd: jmp 0x3f4cfad
0x3f4cfbf: mov 0x88(%rsi),%r12
0x3f4cfc6: movabs $0xfffe000000000000,%r14
(gdb) info registers (key values)
rax 0x7ffffffdea30 rbp 0x7ffffffdea30 rsp 0x7ffffffdea30
rdx 0x7ffffeffeff8 rsi 0x7fffda88a160 rip 0x3f4cfb6
r14 0xfffe000000000000 r15 0xfffe000000000002
(gdb) info threads
* 1 "2.1.148" 0x3f4cfb6 in ?? () <- crash, main thread
2 "2.1.148" __futex_abstimed_wait_common64 <- parked
3 "JITWorker" __futex_abstimed_wait_common64 <- parked
4 "Bun Pool 0" 0x2b6ca43 in ?? () <- parked
5 "Bun Pool 1" 0x2b6ca43 in ?? () <- parked
Representative bun.report URL: https://bun.report/1.3.14/B_1521eeddkggggEugggC4wvo4E+ypR_sup6+D_sup6+D_sup6+D_sup6+D_sup6+D_sup6+D_sup6+D_sup6+D_sup6+DA2+//Bxggmg5C
Steps to Reproduce
- Ubuntu 24.04.4 LTS guest in VirtualBox, kernel 6.17.0-23-generic, on an Intel i5-12450H (Alder Lake) host. ~3.8 GB RAM allocated to the guest.
- Install Claude Code (native installer; reproduced on 2.1.148).
- Run
claude --help(orclaude doctor, orclaude). - Observe immediate Bun v1.3.14 segfault (~160ms), before any output.
claude --versionis the only command that succeeds.
Reproduces regardless of BUN_JSC_* GC/JIT flags and regardless of ulimit -s.
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
A pre-1.3.14-Bun build (prior to the auto-update to the 1.3.14 baseline runtime).
Claude Code Version
2.1.148
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
Terminal/Shell
bash
- Binary verified healthy:
filereports a valid ELF 64-bit x86-64 Linux executable (BuildID2eabd56b93310e766961206f003fc2e163ec5f86), 237 MB, not stripped. The install is not corrupt. - All
@anthropic-ai/claude-code*platform packages ship the identical baseline Bun binary, so version pinning / platform-package selection gives no escape (consistent with #57853). - Likely related but distinct: #57853 (mid-session GC segfault) and the stale #27497. Both are on kernel 6.17.0; #57853 is AMD Ryzen, this report is Intel Alder Lake — so the crash spans CPU vendors and the common factor is the kernel + the Bun 1.3.14 baseline binary.
- Runs inside a VirtualBox guest with ~3.8 GB RAM. With
ulimit -s unlimitedthe process was OOM-Killedrather than segfaulting; at finite stack sizes it segfaults as above. Low guest RAM may be a contributing stressor but is not the primary cause (the fault is a real frame-overrun, not an allocation failure). - Request: a non-baseline x86-64 build, or a fix to the JSC call-frame size/stack-limit computation that overruns the guard page on kernel 6.17.0.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗