[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

Status Open
Reported on v2.1.259
Maintainer reply None cached
Activity 1 comment · opened Sep 3, 2026

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::parallelNotEmptyMarkedBlockSource during 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):

https://bun.report/1.4.1/l_1e6b1ba4mgggkQuhogCol64zDg+7spE6hgopEknwupEy19vpE+xjnpE8okppEmyrppE6lyv0Dw56n1DiqgmB2gkoCA3Aql64zD

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.

  1. Install the native Linux x64 build (here via mise / aqua registry anthropics/claude-code).
  2. Run interactive sessions on a large repo / long conversations with many tool calls (Bash, WebFetch, subagents, MCP servers connected).
  3. 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

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗