[BUG] Native binary (Bun/JSC) aborts on ARM64 Linux with 64K page size kernels

[alan-cooney-dsit]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

The Claude Code native binary aborts immediately on ARM64 Linux systems
with 64K page size kernels (common on HPC/Cray systems, some server distros).

The binary is built on Bun, which uses JavaScriptCore (JSC). JSC's JIT
compiler and memory allocator assume 4K pages and call abort() during
VM initialization on 64K page kernels.

What Should Happen?

Install should complete

Error Messages/Logs

bash: line 150: 31214 Aborted                 "$binary_path" install ${TARGET:+"$TARGET"}

Steps to Reproduce

Run the native installer on any ARM64 Linux system with 64K pages:

curl -fsSL https://claude.ai/install.sh | bash
Setting up Claude Code...
bash: line 150: 31214 Aborted                 "$binary_path" install ${TARGET:+"$TARGET"}

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

na

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

No response

[github-actions]

Found 2 possible duplicate issues:

1. [BUG] Native installer reports success but fails to install binary on Raspberry Pi (ARM64) #20490
2. [BUG] Claude Code crashes with "double free or corruption" on Android/ARM64 (aarch64) #12160

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[ant-kurt]

Huh, we do have a Linux ARM64 binary - see manifest https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/2.1.42/manifest.json

Can you share what distro you're using? Can you try directly downloading the binary (from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/2.1.42/linux-arm64/claude) and see if that runs properly - which would indicate an issue with the install.sh script?

[elch10]

I have the same issue, but this doesnt work

$ wget  https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/2.1.42/linux-arm64/claude                                                                                                                                              
--2026-02-18 07:14:26--  https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/2.1.42/linux-arm64/claude             
Resolving storage.googleapis.com (storage.googleapis.com)... 172.253.62.207, 142.251.167.207, 142.251.179.207, ...                                                       
Connecting to storage.googleapis.com (storage.googleapis.com)|172.253.62.207|:443... connected.                                                                          
HTTP request sent, awaiting response... 200 OK                                                                                                                           
Length: 220582329 (210M) [application/octet-stream]                                                                                                                      
Saving to: ‘claude’                                                                                                                                                      
                                                                                                                                                                         
claude                                     100%[=====================================================================================>] 210.36M   231MB/s    in 0.9s     
                                                                                                                                                                         
2026-02-18 07:14:27 (231 MB/s) - ‘claude’ saved [220582329/220582329]                                                                                                    
                                                                                                                                                                         
$ chmod +x ./claude                                                                                            
$ ./claude 
Aborted                                                                              

I've opened the same issue with more details #26509

This error appears as claude starts propose to use native installer (2.1.34 I think)

[alan-cooney-dsit]

Updated after some more debugging - notes from claude code:

strace shows the binary self-aborts via tgkill(SIGABRT) during
Bun/JSC initialization, before any JS code runs. The ELF LOAD segment
alignment is already 0x10000 (64K) so this is not an ELF alignment issue —
it's JSC's internal memory management assuming 4K pages.

Relevant strings in the binary:

"Failed to allocate JavaScriptCore Virtual Machine"

Environment
System: HPE Cray (Isambard HPC), SLES 15 SP6
Kernel: Linux 6.4.0-...-cray_shasta_c_64k (64K page size)
Arch: aarch64 (getconf PAGESIZE = 65536)
Binary tested: linux-arm64 v2.1.45 (glibc), checksum verified
glibc: 2.38
ldd: All deps resolve correctly

[jgehrcke]

Huh, we do have a Linux ARM64 binary

@ant-kurt that's understood :) The original poster described the root cause already with precision.

JSC's JIT assumes 4K pages and calls abort() during VM initialization on 64K page kernels.

This is the cause, also on my system. After debugging this Claude crash with (a working version of) Claude, a high-level conclusion is (emphasis mine):

A proper fix that preserves performance would require deeper work: making bmalloc/libpas and JSC's JIT work correctly with 64K pages, which is why this hasn't been done upstream yet

---

A bit of background.

Here is the check that fails:

https://github.com/WebKit/WebKit/blob/120aa0417b02b75593c2789d39fb4cb41502fb91/Source/WTF/wtf/PageBlock.cpp#L65

Why don't we see the error message? I did let Claude debug the crash with strace and with a crash dump and with gdb.

Relevant output:

                                                                                                                                                       
[...] This is the entire function at 0x3f853c0:
                                                                                                                                                                     
  sub   sp, sp, #0x30                                           
  stp   x29, x30, [sp, #32]                                                                                                                                          
  add   x29, sp, #0x20                                       
  stur  w0, [x29, #-4]       ; store line number (65)                                                                                                                
  str   x1, [sp, #16]        ; store file ("PageBlock.cpp")                                                                                                          
  str   x2, [sp, #8]         ; store function ("WTF::pageSize()")                                                                                                    
  bl    abort@plt             ; call abort() — no printing whatsoever                                                                                                
                                                                                                                                                                     

Bun builds WebKit in a release/optimized configuration where
RELEASE_ASSERT_WITH_MESSAGE is compiled down to the equivalent
of plain RELEASE_ASSERT 
[...] discards the human-readable message string entirely. [...]

Claude also says that

The fix already exists in WebKit's own code — USE(64KB_PAGE_BLOCK) sets CeilingOnPageSize = 64 * KB, which would make the assertion pass.

I followed up on that, and ignorantly doing USE(64KB_PAGE_BLOCK) is not viable pathway for now, because this disables the JIT and has other significant side effects:

[...]
             
  The WebKit cmake configuration at Source/cmake/WebKitFeatures.cmake:62-91 spells it out clearly:                                 
                                                                                                                                   
  option(USE_64KB_PAGE_BLOCK "Support 64 KB userspace page size (reduces security and performance)" OFF)
                                                                                                                                   
  if (USE_64KB_PAGE_BLOCK)                                                                                                         
      set(ENABLE_JIT_DEFAULT OFF)        # ← JIT disabled!                                                                         
      set(ENABLE_FTL_DEFAULT OFF)        # ← FTL (top-tier optimizer) disabled!                                                    
      set(USE_SYSTEM_MALLOC_DEFAULT OFF)                                                                                           
      set(USE_MIMALLOC_DEFAULT ON)       # ← switches from bmalloc/libpas to mimalloc                                              

Btw, Claude's debugging results from my test environment (noice):

  Kernel:     Linux 6.14.0-1013-nvidia-64k (aarch64)
  Page size:  65536 (64K)
  Binary:     ELF 64-bit aarch64, dynamically linked, not stripped
              212MB, Bun-based (embeds JavaScriptCore)

  The exact crash, proven via disassembly + GDB

  I traced the full crash path through the core dump and disassembly:

  1. Function entry at 0x4658d40 — this is WTF::Config::initialize() (called during early Bun/JSC startup, before any JS code runs).

  2. Calls sysconf(_SC_PAGESIZE) at 0x4658d64:
  mov  w0, #0x1e          ; _SC_PAGESIZE = 30 on aarch64 linux
  bl   sysconf@plt        ; returns 65536 (0x10000)

  3. Power-of-2 check passes (line 64 of PageBlock.cpp):
  eor  x9, x0, x8        ; x9 = pagesize XOR (pagesize-1)
  cmp  x9, x8            ; checks power-of-2
  b.ls crash_line64       ; 65536 is power of 2 — OK, not taken

  4. The fatal check fails (line 65 of PageBlock.cpp):
  cmp  x0, #0x4, lsl #12 ; compare pagesize with 16384
  b.hi crash_line65       ; if pagesize > 16384, CRASH
                          ; 65536 > 16384 → branch TAKEN

  5. Abort wrapper at 0x46591dc:
  ; Loads assertion metadata:
  ;   x1 = "vendor/WebKit/Source/WTF/wtf/PageBlock.cpp"
  ;   x2 = "size_t WTF::pageSize()"
  ;   w0 = 0x41 (65) — line number
  bl   0x3f853c0          ; → calls abort()

  6. abort() fires SIGABRT, confirmed by strace:
  tgkill(1734368, 1734368, SIGABRT)
  --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL} ---
  +++ killed by SIGABRT (core dumped) +++

  GDB backtrace from core dump

  #0  libc.so.6  (in __kernel_rt_sigreturn)
  #1  raise()
  #2  abort()
  #3  0x3f853dc  — abort wrapper (PageBlock.cpp:65, WTF::pageSize())
  (Stack is truncated due to frame corruption from the abort handler, but manual frame walking confirmed 0x46591f4 as the caller.)

[jgehrcke]

And there's that wonderful code comment added by this commit:

WebKit/WebKit@83378c8

[alan-cooney-dsit]

@ant-kurt is the new information helpful?