Claude Code Segmentation fault

Resolved 💬 3 comments Opened May 22, 2026 by ar005 Closed May 23, 2026

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_wait at the time of the crash — the fault is on the main thread during JSC call-frame setup, not in GC.
  • Setting BUN_JSC_numberOfGCMarkers=1 does 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=1
  • BUN_JSC_useConcurrentGC=0
  • BUN_JSC_useJIT=0 (changes the LLInt vs JIT frame pattern but not the outcome)
  • BUN_JSC_useConcurrentJIT=0
  • ulimit -s at 8192, 16384, and unlimited (8192/16384 → same segfault; unlimited → OOM Killed)
  • 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

  1. 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.
  2. Install Claude Code (native installer; reproduced on 2.1.148).
  3. Run claude --help (or claude doctor, or claude).
  4. Observe immediate Bun v1.3.14 segfault (~160ms), before any output.
  5. claude --version is 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: file reports a valid ELF 64-bit x86-64 Linux executable (BuildID 2eabd56b93310e766961206f003fc2e163ec5f86), 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 unlimited the process was OOM-Killed rather 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.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗