Crash in DFG JIT: Illegal instruction in pas_utils.h (WTF::Vector<DFG::AbstractValue> resize)

[zbennett10]

What version of Bun is running?

1.3.13 (commit 743d2a4)

What platform is your computer?

Windows 10 Home (10.0.19045), x86_64_baseline

Crash report

https://bun.report/1.3.13/e_1743d2a4mgkgkEuhogC0pj7nDo7v83Dqkx0xDg13goDim4goD+91g2C6/k91Cm5+81Cwy981Ckqi5mDg9mnuD44o8vD6q6xmDgz2xmD6/0xmDm3stmDwx20uDgx/08C+zx/6Cgpjj9CA3s//Bt28woyD

What happened?

panic(thread 29180): Illegal instruction at address 0x7FF68DBBC69A

Bun SIGILL'd during a long-running Claude Code session (~4.5 min of wall-clock, RSS 1.10 GB, commit 11.26 GB, 556k page faults). Decoded stack trace shows the crash originates in WebKit's bmalloc (pas_utils.h:286 assert), reached via JSC's DFG CFA (Control Flow Analysis) phase while resizing a WTF::Vector<JSC::DFG::AbstractValue> on the JIT worker thread.

Context chain (from the decoded report):

• pas_utils.h:286 — assertion failure
• pas_page_malloc.c / pas_large_free_heap_deferred_commit_log.c — deferred commit path
• pas_large_heap.c — large allocation
• JSC DFG CFA phase → JIT compilation thread

The process was doing normal tool-call / string work — no JS eval, no dynamic code load — so this looks like DFG JIT compaction running into a bad state under memory pressure, not user code triggering it.

What steps can reproduce the bug?

Not deterministically reproducible; happened during a long Claude Code session with heavy context. Happy to rerun with BUN_JSC_useDFGJIT=0 or capture a minidump if it recurs and that would help.

Additional information

• Features reported by the crash report: spawn, standalone_executable, yaml_parse, claude_code, WebSocket, fetch
• Machine: 17.09 GB RAM, session RSS peak 1.10 GB (so the crash isn't simple OOM — system had headroom)
• Shell: bash

[github-actions]

Found 2 possible duplicate issues:

1. webkit: re-add -DUSE_SYSTEM_MALLOC=ON to Windows prebuilts #28101
2. Segfault in JIT worker thread during DFG LICM phase on macOS aarch64 (Bun v1.3.11) #28842

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

[Jarred-Sumner]

Investigation update (written by Claude, working with @Jarred-Sumner):

We ran three exhaustive multi-agent bug hunts to find the source of the 11.26 GB commit-charge / 1.10 GB RSS gap that triggers this pas_page_malloc.c:393 assert. The crash itself is straightforward — VirtualAlloc(MEM_COMMIT) fails with ERROR_COMMITMENT_LIMIT, the retry loop exhausts, and PAS_ASSERT traps — the question is what's holding 10 GB of commit charge that isn't in the working set.

What we found and fixed

WebKit/libpas (oven-sh/WebKit, pending):

• pas_thread_local_cache.c scavenger uses DiscardVirtualMemory (doesn't release commit charge) on Windows while the matching commit path uses VirtualAlloc(MEM_COMMIT) — per-thread TLC commit ratchets to high-water mark. Fixed by switching to VirtualFree(MEM_DECOMMIT). Bounded by live_threads × peak_TLC_size, so contributes but isn't the full 10 GB.
• pas_page_malloc.c VirtualQuery return values were unchecked in the exact loop that crashed (latent UB on failure). Hardened.
• StructureAlignedMemoryAllocator.cpp missing null check before OSAllocator::commit on Windows. Fixed.

Bun native — three small leaks found along the way, none explain this crash but worth fixing:

• linear_fifo: free old buffer when growing while empty #29415 — LinearFifo.ensureTotalCapacity leaks the old buffer when growing while empty (hits WebSocket send buffers + event-loop task queue)
• subprocess: always clean up stdio_pipes in finalizeStreams #29416 — subprocess.finalizeStreams skips stdio_pipes cleanup when .stdio was never accessed
• process(windows): free SyncWindowsPipeReader chunks backing #29417 — SyncWindowsPipeReader leaks the chunks ArrayList backing per spawnSync

What we ruled out

• libpas large-heap / segregated-heap commit/decommit — symmetric on Windows
• OSAllocatorWin, JSC MarkedBlock, ExecutableAllocator, StructureMemoryManager — all lazy-commit + scavenger-decommit correctly
• Gigacage — disabled on Windows (GIGACAGE_ENABLED=0)
• mimalloc v3 — arenas are MEM_RESERVE-only on Windows, purge after 1 s does VirtualFree(MEM_DECOMMIT); we also pulled latest dev3
• Resizable ArrayBuffer / Wasm memory — the only WebKit path that can produce multi-GB commit≫RSS, but Claude Code doesn't use it (grepped the bundle and deps)

Still unknown — help us narrow it down

Nothing above accounts for the full 10 GB. If it recurs, you can ask Claude (in your Claude Code session) to capture an address-space breakdown for us — just paste this prompt:

Write a small Bun script using bun:ffi that calls kernel32.VirtualQuery in a loop from address 0 upward over this process's address space, and for every region with State == MEM_COMMIT (0x1000) record {RegionSize, Protect, Type, AllocationBase}. Bucket the results by AllocationBase (sum RegionSize per base), sort descending, and print the top 30 along with total committed bytes and process.memoryUsage(). Save it as vmem-walk.js and run it with bun vmem-walk.js, then show me the output.

Run that once commit climbs past a few GB (you can watch Task Manager's "Commit size" column for the bun process). The output will tell us exactly which reservation is holding the charge. Paste it here and we'll trace it back to the allocator.