[BUG] Claude Code v2.1.63 — frequent SIGABRT crash due to sudden memory exhaustion. Core files analyzed

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?

Using Claude Code interactively for short sessions doing a variety of
standard tasks (code editing, test writing, git operations, file
exploration). No particular task type is associated with the crashes —
they occur during normal mixed usage. The crash frequency is high:
approximately every 20-40 minutes. Core file "cross analysis" shows very
consistent conditions right before failure (see details at tail end of this report).

The memory spike appears to happen very suddenly. Monitoring the process
memory usage shows ~1.5% RSS (approximately 500-600 MB on a 32 GB
machine) in the moments before the process abruptly aborts. There is no
gradual ramp-up visible — the process jumps from normal memory usage to
crashing instantly.

PLATFORM
--------
OS: Ubuntu 22.04.5 LTS (x86_64)
Kernel: 6.8.0-101-generic (PREEMPT_DYNAMIC)
CPU: AMD Ryzen 7 2700 Eight-Core (16 threads)
RAM: 32 GB total, ~18 GB available at time of crash
Swap: 2 GB (unused at time of crash)

ulimit -d (data segment): 16000000 KB (~15.3 GB)
ulimit -m (max RSS): 16000000 KB (~15.3 GB)
ulimit -v (virtual memory): unlimited

KERNEL MEMORY PARAMETERS
------------------------
vm.overcommit_memory: 0 (heuristic)
vm.overcommit_ratio: 50
vm.max_map_count: 65530 (default)
transparent_hugepage: madvise
cgroup v2 memory.max: unlimited (for user slice)

TERMINAL ENVIRONMENT
--------------------
Terminal emulator: GNOME Terminal 3.44.0 (VTE 0.68.0)
Multiplexer: tmux 3.2a
TERM (outer): xterm-256color
TERM (inner/tmux): screen
COLORTERM: truecolor
tmux features: bpaste,ccolour,clipboard,cstyle,focus,title
tput colors: 8
Terminal size: 80x24 (as reported by tput inside tmux)
Locale: en_CA.UTF-8
PTY: /dev/pts/1

SHARED LIBRARY DEPENDENCIES
---------------------------
The Claude binary is nearly fully statically linked. Only system
libraries are dynamically loaded:
libc.so.6 (glibc 2.35, Ubuntu GLIBC 2.35-0ubuntu3.13)
libpthread.so.0 (glibc 2.35)
librt.so.1 (glibc 2.35)
libdl.so.2 (glibc 2.35)
libm.so.6 (glibc 2.35)
ld-linux-x86-64.so.2
Additionally, a native addon (.node shared object) is extracted to
/tmp at runtime and loaded via dlopen. It also appears to link only
against the system glibc.
No ncurses, terminfo, or other terminal libraries are linked — all
terminal handling is done in userspace JS (Ink/React-based TUI).

LIVE PROCESS BASELINE (non-crashed instance for comparison)
-----------------------------------------------------------
A healthy Claude Code process (same version, same session) shows:
VmPeak: 24,812,156 kB (23.7 GB virtual — already very high)
VmSize: 24,811,412 kB
VmRSS: 487,720 kB (476 MB resident — normal)
VmData: 11,501,904 kB (11.0 GB data segment)
VmSwap: 0 kB
Threads: 22
VMAs (map entries): 3133 of 65530 max_map_count

This reveals that even a healthy, non-crashed Claude process
reserves ~24 GB of virtual address space while only using ~476 MB
RSS. The 11 GB VmData is already 72% of the 15.3 GB ulimit -d cap.
The crash may occur when JSC attempts to commit (mprotect) a
portion of this pre-reserved virtual space and the ulimit blocks
the operation.

CLAUDE CODE BUILD
-----------------
Version: 2.1.63
Build time: 2026-02-28T02:43:01Z
Binary: ELF 64-bit LSB executable, x86-64 (not PIE — code
addresses are fixed and reproducible for this build)
Runtime: Bun / JavaScriptCore (WebKit), not Node.js/V8
Binary path: /home/<user>/.local/share/claude/versions/2.1.63
Heap config: max-old-space-size=8192 embedded in binary
(note: this is a V8 flag — possibly vestigial since the
runtime is actually JSC/Bun)

STDERR OUTPUT
-------------
mprotect failed: Cannot allocate memory
Aborted (core dumped)

CRASH DETAILS
-------------
Signal: SIGABRT (self-inflicted via raise() -> abort())
Core file: 19 GB

Crash originated in WebKit's OS-level memory allocator:
WTF::OSAllocator::protect(void*, size_t, bool, bool)
Source file reference found on stack:
vendor/WebKit/Source/WTF/wtf/posix/OSAllocatorPOSIX.cpp

MEMORY STATE AT CRASH
---------------------
Core file ELF program headers: 7549 segments (7548 PT_LOAD)
Total virtual memory mapped: 24.14 GB
Total resident (in core file): 18.82 GB

Largest segments:
vaddr=0x76910ffffb000 memsz=4096 MB filesz= 0 MB (reserved, empty)
vaddr=0x769000000000 memsz=4088 MB filesz=4088 MB (fully populated)
vaddr=0x768dff000000 memsz=4088 MB filesz=4088 MB (fully populated)
vaddr=0x769201500000 memsz=4075 MB filesz=4075 MB (fully populated)
vaddr=0x768f00800000 memsz=4072 MB filesz=4072 MB (fully populated)
vaddr=0x24210000000 memsz=1184 MB filesz=1184 MB
vaddr=0x7693f0f3f000 memsz=1003 MB filesz=1003 MB

The four ~4 GB segments contain raw binary heap data (no printable
strings found in sampling). Total heap data: ~17 GB.

The 15.3 GB ulimit -d / -m caps were exceeded by the process's
~17+ GB resident memory, which likely triggered the failed
mprotect() call in OSAllocatorPOSIX.cpp leading to abort().

THREAD STATE (39 threads total)
-------------------------------
Thread 1 (LWP 82807) — CRASH THREAD:
#0 __pthread_kill_implementation (pthread_kill.c:44)
#1 __pthread_kill_internal (pthread_kill.c:78)
#2 __GI___pthread_kill (pthread_kill.c:89)
#3 __GI_raise (sig=6) (raise.c:26)
#4 __GI_abort (abort.c:100)
#5 0x00000000045e3a38 — abort() wrapper, takes (int, char, char)
#6 0x000076943c47e6a0 — libc internal
#7 0x00000000002cc8e2 — string table: "vendor/WebKit/Source/WTF/wtf/posix/OSAllocatorPOSIX.cpp"
#8 0x0000000000511446 — string table: "static void WTF::OSAllocator::protect(void *, size_t, bool, bool)"

The abort wrapper function at 0x45e3a20 disassembles as:
push %rbp; mov %rsp,%rbp; sub $0x20,%rsp
mov %edi,-0x4(%rbp); mov %rsi,-0x18(%rbp); mov %rdx,-0x10(%rbp)
call 0x6975530 <abort@plt>
This is a RELEASE_ASSERT / CRASH handler that passes file and
function name strings to a diagnostic function, then calls abort().

Thread 13 (LWP 91715) — ACTIVE (executing JS/JIT code at crash time):
#0 0x0000000005479b9f
(deep stack of unresolved JIT addresses, 27 frames)
This was the only thread actively running JavaScript when the
crash occurred.

Thread 6 (LWP 82822) — ACTIVE (possibly GC/runtime):
#0 0x0000000003d0703a
#1 0x00000000045d6906
Short stack, addresses near the abort handler region (~0x45xxxxx),
possibly a JSC garbage collection or runtime thread.

All other 36 threads were in timed waits:

• 22 threads in pthread_cond_timedwait (JSC platform worker pool,

all entering wait via 0x4cdb556)

• 7 threads in libuv-style worker loop (0x3230e93 -> 0x32c2dc9 ->

0x36e57f9 -> start_thread)

• 1 thread in blocking read() on fd 24
• 6 threads in other timed waits

HYPOTHESIS
----------
A sudden, massive memory allocation (~17 GB) occurs with no gradual
buildup — the process goes from ~500 MB RSS to abort in an instant.
This suggests either:
(a) A single allocation request for a very large buffer (e.g., a
multi-GB ArrayBuffer, string concatenation, or JSON parse of a
huge payload)
(b) A rapid loop allocating memory without yielding to GC
The failed mprotect() in OSAllocatorPOSIX.cpp indicates the JSC heap
tried to commit/protect a memory region after the process had already
exceeded the 15.3 GB data segment ulimit, and the kernel refused.

Additionally, the live process baseline shows that even a healthy
instance already reserves ~24 GB virtual with 11 GB VmData — already
72% of the 15.3 GB ulimit -d cap. The crash may not require a single
massive allocation; it may only take a modest commit into the
pre-reserved space to cross the ulimit threshold.

TERMINAL / TUI ANGLE
--------------------
User observation: Claude Code has a long history of terminal-related
misbehavior (screen blinking, mishandling of large Bash tool output,
rendering glitches) across many versions. If this crash shares a root
cause with those issues, the terminal environment is relevant:

• Claude Code uses an Ink (React-based) TUI rendered entirely in

JS — no ncurses or terminfo libraries are linked.

• The process runs inside tmux 3.2a, which advertises the "focus"

capability. Focus-in/focus-out escape sequences are sent on
every window switch, pane change, or even alt-tab — each one
could trigger a React re-render cycle in the Ink TUI layer.

• There is a TERM mismatch: the outer terminal is xterm-256color,

but tmux sets TERM=screen (not screen-256color), while
COLORTERM=truecolor is also set. tput reports only 8 colors.
This inconsistency could cause repeated fallback/negotiation
logic in the rendering path.

• The idle-crash-on-keystroke observation (empty prompt, typed two

characters, immediate core dump) is consistent with a keystroke
or input event triggering a pathological code path in the TUI
layer — e.g., a re-render that causes runaway allocation.

• The large Bash output handling issues the user has observed over

many months could share the same root cause: the Ink layer
attempting to lay out or buffer enormous terminal content,
triggering the same sudden memory spike.

REPRODUCER
----------
No specific reproduction steps — occurs during normal interactive
usage approximately every 20 minutes. Crash frequency is consistent
across sessions.

Notably, at least one crash occurred while the process was completely
idle — no background tasks running, no model thinking in progress,
simply waiting for user input. The user typed two characters into an
empty prompt and the process immediately core-dumped. This rules out
the crash being triggered solely by large API responses or heavy
tool execution.

ADDITIONAL CORE FILES (cross-validation)
----------------------------------------
Three core dumps were collected in a single session, all from
Claude Code v2.1.63:

core.claude.82807 20,207,980,544 bytes (reference, analyzed above)
core.claude.91914 20,268,605,440 bytes
core.claude.97501 20,179,120,128 bytes

All three cores show identical crash characteristics:

• Signal 6 (SIGABRT), si_code=-6 (SI_TKILL — self-inflicted)
• 39 threads in each core
• Same binary: /home/<user>/.local/share/claude/versions/2.1.63
• OSAllocatorPOSIX.cpp / WTF::OSAllocator::protect strings found

in all three cores

• Same ~4 GB heap segment pattern:

core.82807: 7548 LOAD segs, 24.14 GB virtual, 18.82 GB resident
Top segs: 4096/4088/4088/4075/4072 MB

core.91914: 3116 LOAD segs, 24.21 GB virtual, 18.88 GB resident
Top segs: 4100/4096/4088/4088/4072 MB

core.97501: 4557 LOAD segs, 27.92 GB virtual, 18.79 GB resident
Top segs: 4101/4096/4094/4088/4088 MB

The memory footprint is remarkably consistent across all three
crashes (~18.8 GB resident, four ~4 GB heap segments). The
variation in LOAD segment count (3116–7548) and virtual size
(24–28 GB) suggests differing degrees of address space
fragmentation at crash time, but the resident memory consumed is
nearly identical each time.

What Should Happen?

Up until a few days ago, I would typically run Claude Code all day with no problems. I'm a daily user with months of usage experience.

Error Messages/Logs

mprotect failed: Cannot allocate memory
Aborted (core dumped)

Steps to Reproduce

I've observed the defective behavior several times today. Many of these times in a fresh session and doing nothing more than asking Claude to analyze the core files and help me write this bug report.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.63

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

_No response_