2.1.206 linux-x64 ships a Bun baseline build that segfaults on startup (glibc 2.41)

Closing this as not a claude-code / Bun bug — root cause was faulty RAM on my machine.

Follow-up investigation showed the crashes were non-deterministic (varying fault addresses 0xD0, 0x208..., mixed SIGSEGV/SIGTRAP) and unaffected by version rollback or any runtime env-var workaround. The user had recently swapped RAM. memtester found hundreds of single-bit errors concentrated in a narrow physical region:

FAILURE: 0xfce7ab25fca7eacc != 0xfce7ab25fca7eecc at offset 0x000000000dafa2d0.
FAILURE: 0x7f7fc9725fbf03e8 != 0x7f7fc9725fbf0be8 at offset 0x000000000dafa5d0.
...

Each mismatch differs by a single bit, clustered in one ~4KB band — classic weak/stuck memory cells. The system is non-ECC (EDAC ie31200: No ECC support), so the corruption was silent and only surfaced as random crashes in memory-heavy processes like the claude TUI.

The "baseline Bun build" observation in the original report was real but a red herring; it did not cause the crashes. Apologies for the noise.

Can someone read this AI report and maybe reopen ticket if correct ?
---
Adding a data point from a different environment, since I don't think this is fully explained by the RAM diagnosis above — full repro details below in case it helps re-scope this.

Environment

| Component | Details |
|---|---|
| OS | Ubuntu 26.04 LTS "Resolute Raccoon", glibc 2.43-2ubuntu2 |
| Host CPU | Intel Core i7-10850H (Comet Lake) |
| Virtualization | VirtualBox 7.0.10 VM, cpu-profile=host, native VT-x confirmed via VBox.log (HM: HMR3Init: VT-x w/ nested paging and unrestricted guest execution hw support — not routed through Windows Hypervisor Platform/NEM) |
| Guest CPUID | avx/avx2/fma/bmi1/bmi2 all present — ruled out as a CPU-feature-exposure issue |
| Extension | Claude Code for VS Code 2.1.206 (linux-x64 native binary, ~255 MB) |

Repro

/home/<user>/.vscode/extensions/anthropic.claude-code-2.1.206-linux-x64/resources/native-binary/claude --version

→ Erreur de segmentation (core dumped), 100% reproducible across many separate runs.

Diagnostics

dmesg — identical fault address on every crash:

traps: claude[PID] general protection fault ip:300a990 sp:... error:0 in claude[2e09990,1b38000+36d3000]

strace — crash happens immediately after glibc/TLS init (arch_prctl(ARCH_SET_FS), rseq(), RELRO mprotects, prlimit64, getrandom, two futex(..., FUTEX_WAKE_PRIVATE, ...)), before any real work:

--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++

si_code=SI_KERNEL/si_addr=NULL matches the kernel's translation of a hardware #GP (general protection fault) into SIGSEGV — consistent with the dmesg output above, not a normal page-fault-style segfault.

gdb — backtrace shows the fault happens before main(), inside .init_array/global constructors:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000300a990 in ?? ()
#0  0x0000000000300a990 in ?? ()
#1  0x0000000003007ee8 in ?? ()
#2  0x0000000001c917ad in ?? ()
#3  0x00007fff... in __libc_start_main_impl (main=0x273dec0, argc=2, argv=..., init=0x1c91760, ...) at ../csu/libc-start.c:343
#4  0x0000000001b38e2e in ?? ()

Disassembly at the fault:

0x300a980:      xor    %eax,(%rdx)
0x300a982:      add    %dh,0x48(%rbp,%rcx,1)
0x300a986:      mov    0x231b304(%rip),%eax        # 0x5325c90
0x300a98c:      mov    %ebx,%edi
0x300a98e:      xor    %esi,%esi
=> 0x300a990:   call   *%rax

Frame #2 sits inside init=0x1c91760, called by __libc_start_main_impl, well before main=0x273dec0 is ever reached. The fault is an indirect call through a function pointer loaded from a global (0x5325c90) during static initialization — not an AVX/YMM instruction, so not a CPU-feature-exposure issue.

Ruling out RAM

Given the RAM-corruption finding discussed above, I ran the same check before posting:

sudo memtester 512 1

Loop 1/1:
  Stuck Address       : ok
  Random Value        : ok
  Compare XOR/SUB/MUL/DIV/OR/AND : ok
  Sequential Increment: ok
  Solid Bits          : ok
  Block Sequential    : ok
  Checkerboard        : ok
  Bit Spread          : ok
  Bit Flip            : ok
  Walking Ones/Zeroes : ok
  8-bit / 16-bit Writes: ok
Done.

Clean — no memory errors. So RAM isn't the explanation here.

Unlike the RAM-corruption case described above (varying fault addresses 0xD0/0x208..., mixed SIGSEGV/SIGTRAP, unaffected by version rollback), mine shows the opposite signature:

• Same fault address on every single run (ip:300a990, confirmed identically via gdb across 5+ separate invocations)
• Always plain SIGSEGV/#GP, never SIGTRAP
• Reinstalling 2.1.205 fixes it immediately and reliably — a bad DIMM wouldn't care which binary version is running

Ask

I think this issue may have conflated two unrelated root causes: a genuine RAM problem for the original reporter, and a separate 2.1.206 packaging/runtime regression (possibly the "baseline Bun build" observation from the original report, which may not have been a red herring across the board) affecting other environments deterministically. Could this be reopened, or should I file a fresh issue so the real regression (if still present in the current build) doesn't get lost? Happy to provide the core dump or run further tests.

ok.. do not reopen it's solved. Update of VSCode (+some linux-firmware) solve the issue. So much updates to do every day ! Strange that Claude IA didn't ask to test this (but we still have our own small brain I think...).

<img width="733" height="457" alt="Image" src="https://github.com/user-attachments/assets/c10898b3-a53e-43cc-8811-6bad97038824" />

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.