[BUG] Native Linux build crashes (SIGILL/SIGSEGV) in JSC GC HeapHelper thread, 8x/day on 2.1.258, same Bun 1.4.1 in 2.1.259
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet (searched for
HeapHelper,IsoCellSet,parkConditionallyImpl,bun.report+Illegal instruction) - [x] This is a single bug report
- [x] I am using the latest version of Claude Code (2.1.259; the crashes below were on 2.1.258, and 2.1.259 ships the same Bun 1.4.1 runtime)
What's Wrong?
The native Linux x64 build of Claude Code crashes hard (whole process dies, core dumped) inside the bundled Bun / JavaScriptCore garbage collector. On one machine it crashed 8 times in a single day on 2.1.258, in interactive sessions of varying length and shape (plain claude, --resume, --permission-mode auto, a forked subagent session).
Every crash has the same signature:
- The faulting thread is a JSC GC helper thread named
HeapHelper(7 of 8 crashes; once it was the main thread). - The fault is inside
JSC::IsoCellSet::parallelNotEmptyMarkedBlockSourceduring parallel marking (MarkingConstraintSolver::runExecutionThread→SlotVisitor::drainFromShared). - Bun's crash handler catches the fault, prints the report, and re-raises. The signal alternates between SIGILL (4 crashes) and SIGSEGV (4 crashes); the SIGILL variant dies in
WTF::ParkingLot::parkConditionallyImpl(Lock::lockSlow) called from that same GC function. - No trap instruction (
ud2/int3) exists at the reported fault address, and the address sits mid-instruction inside a function prologue, so this looks like corrupted lock/heap metadata seen by the GC rather than a deliberate assertion.
Decoded Bun crash report for the most recent crash (2.1.258, Bun v1.4.1 e6b1ba42d, linux x86_64, StandaloneExecutable):
Illegal instruction at address 0x039E3455
ParkingLot.cpp:562 WTF::ParkingLot::parkConditionallyImpl
Lock.cpp:51 lockSlow
Lock.h:71 lock
Locker.h:87 Locker
IsoCellSet.cpp:64 JSC::IsoCellSet::parallelNotEmptyMarkedBlockSource
IsoCellSetInlines.h:118 lambda task
MarkingConstraint.cpp:96 doParallelWork
MarkingConstraintSolver.cpp:226 JSC::MarkingConstraintSolver::runExecutionThread
SlotVisitor.cpp:703 JSC::SlotVisitor::drainFromShared
Heap.cpp:1624 operator()
SharedTask.h:91 WTF::SharedTaskFunctor::run
ParallelHelperPool.cpp:113 runTask
ParallelHelperPool.cpp:211 WTF::ParallelHelperPool::Thread::work
AutomaticThread.cpp:247 operator()
Threading.cpp:309 WTF::Thread::entryPoint
ThreadingPOSIX.cpp:269 WTF::wtfThreadEntryPoint
Crash history from coredumpctl list (all on 2.1.258, same binary, same day):
| Time (CEST) | Signal | Faulting thread | Invocation |
|---|---|---|---|
| 10:57 | SIGSEGV | HeapHelper | claude |
| 11:36 | SIGILL | main thread | claude --resume <id> |
| 13:23 | SIGSEGV | HeapHelper | claude --session-id … --fork-session --resume … --model claude-opus-5 --permission-mode auto |
| 15:38 | SIGSEGV | HeapHelper | claude |
| 16:16 | SIGILL | HeapHelper | claude --resume <id> |
| 17:48 | SIGILL | HeapHelper | claude |
| 19:42 | SIGSEGV | HeapHelper | claude --permission-mode auto |
| 19:57 | SIGILL | HeapHelper | claude --permission-mode auto |
The SIGSEGV crashes fault at offsets claude+0x42b378a, +0x42b37de, +0x42b3752, +0x42b36c0, i.e. inside the same parallelNotEmptyMarkedBlockSource function as the SIGILL ones (+0x42b37e1).
Ruled out:
- Not OOM: 62 GiB RAM, ~41 GiB available at the time, no OOM-killer activity in the journal.
- Not a CPU feature problem: Intel Core Ultra X7 358H (AVX2 etc. present); the SIGILL is raised by Bun's handler via
raise()(si_code: SI_TKILL), not by the CPU. - No OS/package change coincides with the crashes.
What Should Happen?
The process should not crash. If the GC hits an inconsistent state it should at minimum not take the whole session down.
Error Messages/Logs
coredumpctl info for the 19:57 crash (crashing thread only; binary has no usable symbol table, hence n/a):
Signal: 4 (ILL) si_code: SI_TKILL
TID: 986343 (HeapHelper)
Executable: ~/.local/share/mise/installs/claude/2.1.258/claude
Command Line: claude --permission-mode auto
#0 0x00007f5c3889a17c n/a (libc.so.6 + 0x9a17c)
#1 0x00007f5c3883e5d0 raise (libc.so.6 + 0x3e5d0)
#2 0x000000000373c002 n/a (claude + 0x353c002)
#3 0x000000000373b3ed n/a (claude + 0x353b3ed)
#4 0x000000000373bdb4 n/a (claude + 0x353bdb4)
#5 0x00007f5c3883e6f0 n/a (libc.so.6 + 0x3e6f0) <- signal trampoline
#6 0x00000000039e3455 n/a (claude + 0x37e3455) <- ParkingLot::parkConditionallyImpl
#7 0x00000000044b37e1 n/a (claude + 0x42b37e1) <- IsoCellSet::parallelNotEmptyMarkedBlockSource
#8 0x00000000044a001e n/a (claude + 0x42a001e)
#9 0x00000000044ba073 n/a (claude + 0x42ba073)
#10 0x00000000044bfb5a n/a (claude + 0x42bfb5a)
#11 0x000000000449c720 n/a (claude + 0x429c720)
#12 0x00000000044a488f n/a (claude + 0x42a488f)
#13 0x00000000044a5724 n/a (claude + 0x42a5724)
#14 0x0000000003a3e45e n/a (claude + 0x383e45e)
#15 0x0000000003a9f599 n/a (claude + 0x389f599)
#16 0x00007f5c388980a2 n/a (libc.so.6 + 0x980a2)
#17 0x00007f5c3892080c n/a (libc.so.6 + 0x12080c)
The main thread was blocked in pthread_cond_wait (waiting for the GC helpers) and the other HeapHelper threads were parked in the same wait, consistent with a GC cycle in progress.
In the 19:57 case the session had just received a Bash tool result (preceded by a WebFetch call) one second before the crash. Other crashes happened at arbitrary points in normal interactive use.
Core dumps (≈100 MB each, zstd) are retained locally and can be shared privately on request.
Steps to Reproduce
I don't have a minimal reproducer; it happens during ordinary interactive use, several times a day.
- Install the native Linux x64 build (here via
mise/ aqua registryanthropics/claude-code). - Run interactive sessions on a large repo / long conversations with many tool calls (Bash, WebFetch, subagents, MCP servers connected).
- Within minutes to hours, the process dies with SIGILL or SIGSEGV in the JSC GC helper thread and systemd-coredump records a core.
Claude Model
Other (Fable 5.1 and Opus 5 sessions both crashed)
Is this a regression?
I don't know
Last Working Version
Unknown. 2.1.258 was installed 2026-09-02; all 8 crashes are from 2026-09-03.
Claude Code Version
2.1.258 (crashes); now on 2.1.259, which bundles the same Bun v1.4.1 (e6b1ba42d)
Platform
- OS: Arch Linux (Omarchy), kernel 7.1.8-arch1-2
- CPU: Intel Core Ultra X7 358H, x86_64
- RAM: 62 GiB
- Terminal: Hyprland / xdg-terminal-exec, xterm-256color
- Install method: mise (aqua backend), native standalone executable, not npm
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗