›_ Claude Code Issues
Claude Code Issues / #77579

[BUG] Bun 1.4.0 JSC GC use-after-free segfault (SlotVisitor::drain -> MethodTable::visitChildren) at 0x...00000050 on Windows x64 baseline - symbolized trace, reproduces at idle load - CLI 2.1.209

Open 💬 0 comments Opened Jul 14, 2026 by danielw98

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?

The CLI died with a native segfault inside JavaScriptCore's garbage collector, 4m52s into an
ordinary interactive session at very low load. This report adds the piece the other 0x...00000050
reports are missing: a fully symbolized stack trace, plus counter-evidence against the
"concurrency load" and "memory pressure" theories.

panic(main thread): Segmentation fault at address 0x29600000050

Environment

| | |
|---|---|
| Claude Code | 2.1.209 |
| Install | native installer, C:\Users\<user>\.local\bin\claude.exe (240 MB), not npm |
| Host | Windows Terminal, plain claude (no IDE extension, no desktop app) |
| Bundled runtime | Bun v1.4.0 (a505a29), windows x86_64_baseline [StandaloneExecutable] |
| OS | Windows 11 Enterprise, build 26200 |
| CPU | Intel Core i5-13500H (sse42 avx avx2; AVX2-capable, yet the shipped Bun build is baseline) |
| RAM | 15.7 GB |
| MCP | Playwright MCP connected (stdio) |

Bun's own counters at death: Elapsed: 292070ms | RSS: 0.53 GB | Peak: 0.54 GB | Commit: 0.92 GB | Faults: 393205 | Machine: 16.89 GB, fetch(52) spawn(72) abort_signal(16) yaml_parse(62).

What the session was actually doing. Nothing exotic. Over the whole 4m52s lifetime, from the
session transcript: 14 Playwright MCP calls (navigate, snapshot, click, find, tabs), 5 WebSearch,
3 WebFetch, 3 ToolSearch. Zero subagents, zero background tasks. The crash landed while the
main thread was doing routine JS work, not during any user action I could point at.

This is not resource exhaustion and not a concurrency-load bug

  • Peak RSS 0.54 GB / commit 0.92 GB on a 15.7 GB machine, roughly 3% utilization.
  • No subagents and no background tasks were ever spawned in this session, which distinguishes it

from #75538 (same fault-address family, but reported under ~25 concurrent subagents). The same
crash reproduces at effectively idle load, so subagent fan-out is a trigger amplifier at most,
not the cause.

  • Only Bun's own panic handler fired.

Root-cause reading of the trace

The full symbolized trace (below) says the fault is in the GC mark phase, dereferencing a
JSCell whose class-info pointer is garbage:

operationHasOwnProperty (DFG-compiled JS) -> JSObject::hasOwnProperty ->
Structure::materializePropertyTable -> ~DeferGC -> Heap::collectIfNecessaryOrDefer ->
Heap::stopIfNecessarySlow -> Heap::collectInMutatorThread -> Heap::runFixpointPhase ->
SlotVisitor::drain -> SlotVisitor::visitChildren -> JSC::MethodTable::visitChildren at
ClassInfo.h:115, which is where it dies.

So: a DFG-compiled hasOwnProperty materialized a property table, the deferred-GC scope closed,
GC ran synchronously on the mutator thread, and marking then walked a cell that is not a valid
object any more. The fault address shape is the tell: 0x296_00000050 is a read at offset 0x50
off a pointer whose high bits are garbage, which is what a use-after-free or torn cell pointer
looks like, not a null-deref. The other Windows reports show the identical shape with only the high
bits differing (#75538: 0x2CA00000050), which is consistent with one bug corrupting the JSC heap
and the crash surfacing wherever GC next touches the poisoned cell.

That also explains why this family looks like several unrelated bugs: the observed trigger
(fetch, spawn, subagents, MCP churn) is just whatever allocated heavily before the next GC. The
common factor is the JSC heap, not the trigger.

Related issues (same family, please consider consolidating):

  • #75538 - Windows, Bun 1.4.0, 0x2CA00000050, under ~25 concurrent subagents. Same address shape, no trace attached.
  • #69862 - Windows, Bun 1.4.0, segfault on the fetch path.
  • #68168 - Windows, same panic signature.
  • #57853 - Linux, Bun 1.3.14, SlotVisitor::drain GC segfault. Same GC crash site on a different

platform and an older Bun, which suggests this predates 1.4.0 and is not Windows-specific.

Both #57853 and this report are on baseline builds. Worth checking whether the shipped Bun is
built with a JSC configuration that only baseline binaries hit.

What Should Happen?

The CLI should not die with a native segfault during normal operation. Concretely:

  1. The JSC heap corruption behind the 0x...00000050 crash family gets fixed in the bundled Bun.
  2. Failing that, ship a Claude Code build whose Bun is compiled with a GC configuration that does

not fault (or a non-baseline build for AVX2 CPUs, which this machine is).

  1. Regardless of root cause: a native crash should not silently vaporize the session. There is no

crash log written under ~/.claude, and the work in flight is simply gone.

Error Messages/Logs

============================================================
Bun v1.4.0 (a505a2999938c391bd313dad75c110de8ef05853) Windows x64 (baseline)
Windows v10.26200
CPU: sse42 avx avx2
Args: "claude"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(16) fetch(52) jsc spawn(72) standalone_executable yaml_parse(62) claude_code

Elapsed: 292070ms | User: 27218ms | Sys: 5484ms
RSS: 0.53 GB | Peak: 0.54 GB | Commit: 0.92 GB | Faults: 393205 | Machine: 16.89 GB

panic(main thread): Segmentation fault at address 0x29600000050
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Bun crash report: https://bun.report/1.4.0/e_1a505a29mgggkEuhogCsh4q4Bk7gq4Bixnq4Bu6lw4Bqj/v4B6v534Bqq0u5Bkphx4By6gv4B8zwn6Bm0zuoB86/uoBom/uoBmzy7+CA2spBgF

Symbolized stack trace, as decoded by bun.report (top frame first, this is the crash site):

Bun v1.4.0 (a505a29) on windows x86_64_baseline [StandaloneExecutable]
Segmentation fault

ClassInfo.h:115              JSC::MethodTable::visitChildren(...) const     <-- faults here
SlotVisitor.cpp:0            JSC::SlotVisitor::visitChildren
SlotVisitor.cpp:510          JSC::SlotVisitor::drain::<lambda_4>::operator()(...) const
SlotVisitorInlines.h:198     JSC::SlotVisitor::forEachMarkStack
SlotVisitor.cpp:500          JSC::SlotVisitor::drain
SlotVisitor.cpp:783          JSC::SlotVisitor::donateAndDrain
SlotVisitor.cpp:709          JSC::SlotVisitor::drainInParallel
Heap.cpp:1668                JSC::Heap::runFixpointPhase
Heap.cpp:1466                JSC::Heap::runCurrentPhase
Heap.cpp:2114                JSC::Heap::collectInMutatorThread::<lambda_2>::operator()(...) const
ScopedLambda.h:106           WTF::ScopedLambdaFunctor<...>::implFunction
ScopedLambda.h:58            WTF::ScopedLambda<void (...)>::operator()(...) const
MachineStackMarker.cpp:235   JSC::callWithCurrentThreadState
Heap.cpp:2126                JSC::Heap::collectInMutatorThread
Heap.cpp:2095                JSC::Heap::stopIfNecessarySlow
Heap.cpp:2067                JSC::Heap::stopIfNecessarySlow
HeapInlines.h:225            JSC::Heap::stopIfNecessary
Heap.cpp:2905                JSC::Heap::collectIfNecessaryOrDefer
HeapInlines.h:184            JSC::Heap::decrementDeferralDepthAndGCIfNeeded
DeferGCInlines.h:44          JSC::DeferGC::~DeferGC
Structure.cpp:534            JSC::Structure::materializePropertyTable
Structure.h:944              JSC::Structure::ensurePropertyTableIfNotEmpty
StructureInlinesLight.h:94   JSC::Structure::get
JSObject.h:1098              JSC::JSObject::getOwnNonIndexPropertySlot
JSObject.h:1156              JSC::JSObject::getOwnPropertySlotImpl
JSObject.h:1166              JSC::JSObject::getOwnPropertySlot
JSObjectInlines.h:478        JSC::JSObject::hasOwnProperty(...) const
DFGOperations.cpp:4941       operationHasOwnProperty

Note for anyone comparing the two: bun.report renders the fault address as 0x20200000050 while
the terminal printed 0x29600000050. Same crash, same link; the address encoding in the report URL
appears to be lossy. The terminal value is the authoritative one.

Steps to Reproduce

Not deterministic, and I want to be honest about that rather than invent a repro. What I can give
you is the exact shape of the session that died:

  1. Windows 11, launch claude in Windows Terminal (CLI 2.1.209, native installer build).
  2. Have the Playwright MCP server connected over stdio.
  3. Work an ordinary browsing/research task. In this session: 2 browser_navigate, 4

browser_snapshot, 5 browser_click, 2 browser_find, 1 browser_tabs, interleaved with 5
WebSearch and 3 WebFetch calls.

  1. Around the 5 minute mark the process dies with the panic above. Exit is immediate, the session

is unrecoverable, and nothing is written to ~/.claude beyond the truncated transcript.

Given the trace, I would expect the reliable repro to be "allocate enough to force a GC while the
heap already holds a corrupted cell", which is why the surface triggers reported across #75538,
#69862 and #68168 all look different. Anyone trying to reproduce this should probably attack the
JSC heap rather than the individual trigger.

Additional Context

Happy to run a debug build, set BUN_JSC_* GC flags, or capture a full dump if that is useful.
The bun.report link above is already recorded on Bun's side, and bun.report itself points embedded
users back here, since the Bun version is pinned by Claude Code and cannot be upgraded by the user:

This app has Bun built into it. The app developer controls which version of Bun is used, so you'll need to wait for them to release an update to get a newer version.

View original on GitHub ↗