Bun crashes on non-AVX2 CPUs (all versions after v1.3.8)

[DoKoB0512]

How can we reproduce the crash?

Bun crashes when running a simple project on a CPU without AVX2 support using any bun version > v1.3.8. Steps below reproduce the issue from a fresh project.

Steps to reproduce

1. Use a machine/VM with a non-AVX2 CPU (e.g., older Intel/AMD CPU or a VM with AVX2 disabled).
2. Install any bun version after v1.3.8.
3. Create a new blank project using bun init and choose blank.
4. Run bun index.ts

Expected behavior

bun runs the script and prints "hello" (or runs the program) without crashing.

Actual behavior

Bun crashes immediately when running the script.
Bun v1.3.14 (0d9b296) Linux x64 (baseline)
Linux Kernel v6.0.0 | glibc v2.39
Args: "bun" "index.ts"
Features: jsc no_avx2 no_avx tsconfig
Builtins: "bun:main"
Elapsed: 16425ms | User: 13835ms | Sys: 2456ms
RSS: 7.96GB | Peak: 4.02GB | Commit: 7.96GB | Faults: 0 | Machine: 30.00GB

CPU lacks AVX support. Please consider upgrading to a newer CPU.
panic(main thread): Segmentation fault at address 0x39E2EC00000
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

https://bun.report/1.3.14/Ba10d9b296gCggggigD4664tE+ypRgwgnuC6n1/uCmj67uCg02u8Dok4k6D+/3xpF+y0xpFm73rmF0973jEq/ykgDmsyppDg1qguCq5/zhD+6gguCuohysC00hhsC8u5gsCy8wKA285Bgggg4uB

Illegal instruction (core dumped)

Relevant log output

Bun v1.3.14 (0d9b296a) Linux x64 (baseline)
Linux Kernel v6.0.0 | glibc v2.39
Args: "bun" "index.ts"
Features: jsc no_avx2 no_avx tsconfig
Builtins: "bun:main"
Elapsed: 16425ms | User: 13835ms | Sys: 2456ms
RSS: 7.96GB | Peak: 4.02GB | Commit: 7.96GB | Faults: 0 | Machine: 30.00GB

CPU lacks AVX support. Please consider upgrading to a newer CPU.
panic(main thread): Segmentation fault at address 0x39E2EC00000
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

 https://bun.report/1.3.14/Ba10d9b296gCggggigD4664tE+ypRgwgnuC6n1/uCmj67uCg02u8Dok4k6D+/3xpF+y0xpFm73rmF0973jEq/ykgDmsyppDg1qguCq5/zhD+6gguCuohysC00hhsC8u5gsCy8wKA285Bgggg4uB

Illegal instruction (core dumped)

Stack Trace (bun.report)

Bun v1.3.14 (0d9b296) on linux x86_64_baseline [AutoCommand]

Segmentation fault at address 0x39E2EC00000

• encoding.zig:215: runtime.webcore.encoding.toBunStringComptime
• string.zig:204: string.string.String.cloneUTF8
• ModuleLoader.zig:1150: jsc.ModuleLoader.getHardcodedModule
• ModuleLoader.zig:1175: jsc.ModuleLoader.fetchBuiltinModule
• ModuleLoader.zig:861: jsc.ModuleLoader.Bun__fetchBuiltinModule
• ModuleLoader.cpp:977: JSC::JSValue Bun::fetchESMSourceCode<true>
• ModuleLoader.cpp:1206: Bun::fetchESMSourceCodeAsync
• ZigGlobalObject.cpp:3543: Zig::GlobalObject::moduleLoaderFetch
• JSModuleLoader.cpp:531: JSC::JSModuleLoader::fetch
• JSModuleLoader.cpp:374: JSC::JSModuleLoader::loadModule
• Completion.cpp:198: JSC::loadAndEvaluateModule
• bindings.cpp:3601: JSC__JSModuleLoader__loadAndEvaluateModule
• JSModuleLoader.zig:39: jsc.JSModuleLoader.JSModuleLoader.loadAndEvaluateModule
• VirtualMachine.zig:2339: jsc.VirtualMachine.reloadEntryPoint
• VirtualMachine.zig:2457: jsc.VirtualMachine.loadEntryPoint
• bun.js.zig:401: bun.js.Run.start
• jsc.zig:234: jsc.jsc.OpaqueWrap.callback
• bindings.cpp:4899: JSC__VM__holdAPILock
• VM.zig:35: jsc.VM.VM.holdAPILock
• bun.js.zig:302: bun.js.Run.boot
• run_command.zig:1562: cli.run_command.RunCommand._bootAndHandleError
• run_command.zig:1642: cli.run_command.RunCommand.maybeOpenWithBunJS
• run_command.zig:1691: cli.run_command.RunCommand.exec
• cli.zig:829: cli.cli.Command.start
• cli.zig:20: cli.cli.Cli.start
• main.zig:66: main.main
• start.zig:618: start.callMain
• start.zig:587: start.callMainWithArgs
• start.zig:602: main

Features: tsconfig, jsc, no_avx2, no_avx

[github-actions]

Found 3 possible duplicate issues:

1. Probabilistic SIGILL crash on no-AVX CPU with deep async recursion (baseline build) #27844
2. Illegal Instruction in macOS intel without AVX2 #26872
3. Crash on Windows x64 (no AVX/AVX2) — "attempt to use null value" panic in v1.3.11 #28399

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

[DoKoB0512]

Probably related - oven-sh/WebKit#198

[DoKoB0512]

Here's repoted logs and stack trace when using with Bun v1.3.13 linux-x64 baseline

Bun v1.3.13 (bf2e2cec) Linux x64 (baseline)
Linux Kernel v6.0.0 | glibc v2.39
Args: "bun" "main.ts"
Features: dotenv jsc no_avx2 no_avx tsconfig tsconfig_paths
Builtins: "bun:main"
Elapsed: 16886ms | User: 13886ms | Sys: 2814ms
RSS: 4.64GB | Peak: 4.03GB | Commit: 4.64GB | Faults: 0 | Machine: 30.00GB

CPU lacks AVX support. Please consider upgrading to a newer CPU.
panic(main thread): Segmentation fault at address 0x2DF2B400000
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

 https://bun.report/1.3.13/Ba1bf2e2cegGgwggigD4vyi7E+ypRg8gi+Cm67/qDmxp+qD+//h3D60ntoE2g7rlE07sm3F_2377jE2377jE2377jE2377jE2377jE2377jE2377jE2377jE2377jE2377jEA2+tBggggorB

Illegal instruction (core dumped)

Bun v1.3.13 ([`bf2e2ce`](<https://github.com/oven-sh/bun/tree/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79>)) on linux x86_64_baseline [AutoCommand]

Segmentation fault at address 0x433AEC00000

- [`encoding.zig:215`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/src/bun.js/webcore/encoding.zig#L215>): `bun.js.webcore.encoding.toBunStringComptime`
- [`string.zig:208`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/src/string.zig#L208>): `string.String.cloneUTF8`
- [`ModuleLoader.zig:1150`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/src/bun.js/ModuleLoader.zig#L1150>): `bun.js.ModuleLoader.getHardcodedModule`
- [`ModuleLoader.zig:1175`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/src/bun.js/ModuleLoader.zig#L1175>): `bun.js.ModuleLoader.fetchBuiltinModule`
- [`ModuleLoader.zig:861`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/src/bun.js/ModuleLoader.zig#L861>): `Bun__fetchBuiltinModule`
- [`ModuleLoader.cpp:971`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/src/bun.js/bindings/ModuleLoader.cpp#L971>): `JSC::JSValue Bun::fetchESMSourceCode<true>`
- [`ModuleLoader.cpp:1200`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/src/bun.js/bindings/ModuleLoader.cpp#L1200>): `Bun::fetchESMSourceCodeAsync`
- [`ZigGlobalObject.cpp:3386`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/src/bun.js/bindings/ZigGlobalObject.cpp#L3386>): `Zig::GlobalObject::moduleLoaderFetch`
- [`JSModuleLoader.cpp:277`](<https://github.com/oven-sh/WebKit/blob/bun-bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/Source/JavaScriptCore/runtime/JSModuleLoader.cpp#L277>): `JSC::JSModuleLoader::fetch`
- [`JSModuleLoader.cpp:509`](<https://github.com/oven-sh/WebKit/blob/bun-bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/Source/JavaScriptCore/runtime/JSModuleLoader.cpp#L509>): `JSC::moduleLoaderFetch`
- *1 unknown/js code*
- [`ld-temp.o:0`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/ld-temp.o#L0>): `llint_op_call`
- [`ld-temp.o:0`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/ld-temp.o#L0>): `llint_op_call`
- [`ld-temp.o:0`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/ld-temp.o#L0>): `llint_op_call`
- [`ld-temp.o:0`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/ld-temp.o#L0>): `llint_op_call`
- [`ld-temp.o:0`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/ld-temp.o#L0>): `llint_op_call`
- [`ld-temp.o:0`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/ld-temp.o#L0>): `llint_op_call`
- [`ld-temp.o:0`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/ld-temp.o#L0>): `llint_op_call`
- [`ld-temp.o:0`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/ld-temp.o#L0>): `llint_op_call`
- [`ld-temp.o:0`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/ld-temp.o#L0>): `llint_op_call`
- [`ld-temp.o:0`](<https://github.com/oven-sh/bun/blob/bf2e2cecf27e800962b1e7f03d66278f9d5d2e79/ld-temp.o#L0>): `llint_op_call`

Features: jsc, no\_avx2, no\_avx

[Jarred-Sumner]

@robobun this still seems to be occurring as of Bun v1.3.14. Can you deeply review the WebKit code (note "jsc" - that means javascriptcore was initialized) and the stack trace shows it's related to module resolution or module evaluation (fetch) and figure out where else this might be going wrong? Maybe more JIT tiers or WASM have similar and incorrect code? Worst case you could download the baseline build of bun and use a CPU emulator or valgrind and see where it hits illegal instruction?

[robobun]

⚠️ Investigated but could not reproduce. Findings so far:

1. The shipped bun-v1.3.14/bun-linux-x64-baseline-profile binary passes the static baseline verifier — all AVX/AVX2/AVX-512 instructions in .text live in symbols that are runtime-dispatched behind a CPUID gate (600+ allowlisted entries, 0 violations).
2. simdutf runtime dispatcher is correct: Nehalem CPUs pick the westmere (SSE4.2) backend.
3. The baseline WebKit tarball is also correct: per-function target-features wraps only haswell::implementation::* and icelake::implementation::*; dispatcher stubs and base-class virtuals stay target-cpu=nehalem.
4. Bun Zig code is built with -Dcpu=nehalem for baseline; all @Vector(16, u8)/@Vector(8, u16) uses are comptime Environment.enableSIMD-gated (false on baseline).
5. BoringSSL dispatches via CPUID-gated CRYPTO_is_*_capable helpers; none are reachable from the cloneUTF8(entry_point.contents) crash path at startup.

The 16425ms elapsed / 8GB RSS / 0 faults in the panic header suggest the crash is not at module-load time but deeper into execution — the stack trace lines may be stale after a runaway allocation. Cannot reproduce without a non-AVX host or a QEMU/SDE emulator (not available in this container).

Handing off — someone with the hardware would need to run bun --smol index.ts and collect a core dump to find the specific instruction that traps.

[DoKoB0512]

Some more info related to the CPU using lscpu command:

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  8
  On-line CPU(s) list:   0-7
Vendor ID:               AuthenticAMD
  Model name:            QEMU Virtual CPU version 2.5+
    CPU family:          6
    Model:               6
    Thread(s) per core:  1
    Core(s) per socket:  1
    Socket(s):           8
    Stepping:            3
    BogoMIPS:            6190.69
    Flags:               fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm nopl cpuid tsc_known_freq pni cx16
                         x2apic hypervisor lahf_lm 3dnowprefetch vmmcall
Virtualization features:
  Hypervisor vendor:     KVM
  Virtualization type:   full
Caches (sum of all):
  L1d:                   512 KiB (8 instances)
  L1i:                   512 KiB (8 instances)
  L2:                    4 MiB (8 instances)
  L3:                    128 MiB (8 instances)
NUMA:
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-7
Vulnerabilities:
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Retbleed:              Not affected
  Spec store bypass:     Vulnerable
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
  Srbds:                 Not affected
  Tsx async abort:       Not affected

[net1957]

I have the same problem on windows 10 with an old processor and Ruby+Devkit 4.0.3-1 (x64)

`
D:\Dvlt\ruby\projects_test\R81>bin\bun --version

Bun v1.3.14 (0d9b296) Windows x64
Windows v.win10_cu
CPU: sse42 avx
Args:
Features: no_avx2

panic: Illegal instruction at address 0x7FF6209AF82C
panicked during a panic. Aborting.
`

[robobun]

Reproduced and root-caused. The reporter's QEMU vCPU only advertises SSE3 (no SSE4.1/4.2/POPCNT — not just no AVX), which is below Bun's Nehalem baseline.

Why this regressed in v1.3.9: oven-sh/WebKit@596e48e started passing -march=nehalem to the prebuilt WebKit build. That defines __SSE4_2__, which makes simdutf set SIMDUTF_CAN_ALWAYS_RUN_WESTMERE=1 → SIMDUTF_IMPLEMENTATION_FALLBACK=0 → the scalar fallback is compiled out. On a pre-SSE4.2 host, simdutf's dispatcher finds no matching kernel among {icelake, haswell, westmere} and silently returns an unsupported_implementation stub whose every function returns 0/false/{OTHER,0}.

Why it eats 4 GB for 16 seconds before crashing: firstNonASCII now returns Some(0) even for an empty slice, so the while (firstNonASCII(remaining)) loop in toUTF16Alloc never exits; remaining[1..] on the empty slice underflows len to SIZE_MAX, and the loop walks ~1 GB of adjacent heap byte-by-byte (appending a u16 for each) until it hits an unmapped page. gdb shows ~1.04 billion iterations at the fault, matching the 4 GB peak RSS.

No emulator needed to reproduce: SIMDUTF_FORCE_IMPLEMENTATION=<any-unknown-name> bun -e '1' installs the same stub and reproduces the identical crash fingerprint on any machine.

Fix in #30642: probe simdutf at startup and fail fast with a clear "this CPU is missing SSE4.2, enable -cpu host in your VM" diagnostic instead of the opaque crash; also guard firstNonASCII against the underflow.

[DoKoB0512]

The machine that we are using is a rented server. Does this mean that people with CPUs that does not support newer SSE version can't run/update their bun version? Can you guys update the webkit's code to provide support for atleast SSE-SSE3 versions?

[pongo]

I have the same issue. bun-v1.3.14/bun-linux-x64-baseline

bun -e "console.log(1)" killed with OOM

lscpu:

Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          46 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   1
  On-line CPU(s) list:    0
Vendor ID:                GenuineIntel
  Model name:             QEMU Virtual CPU version 2.5+
    CPU family:           6
    Model:                13
    Thread(s) per core:   1
    Core(s) per socket:   1
    Socket(s):            1
    Stepping:             3
    BogoMIPS:             4799.99
    Flags:                fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl xtopology cpuid tsc_known_freq pni cx16 x2apic hypervisor lahf_lm p
                          ti
Virtualization features:
  Hypervisor vendor:      KVM
  Virtualization type:    full
Caches (sum of all):
  L1d:                    32 KiB (1 instance)
  L1i:                    32 KiB (1 instance)
  L2:                     4 MiB (1 instance)
  L3:                     16 MiB (1 instance)
NUMA:
  NUMA node(s):           1
  NUMA node0 CPU(s):      0
Vulnerabilities:
  Gather data sampling:   Not affected
  Itlb multihit:          KVM: Mitigation: VMX unsupported
  L1tf:                   Mitigation; PTE Inversion
  Mds:                    Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
  Meltdown:               Mitigation; PTI
  Mmio stale data:        Unknown: No mitigations
  Reg file data sampling: Not affected
  Retbleed:               Not affected
  Spec rstack overflow:   Not affected
  Spec store bypass:      Vulnerable
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Retpolines; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Retpoline
  Srbds:                  Not affected
  Tsx async abort:        Not affected