zig2 seems to crash systems using Intel's i5-1135G7 CPUs? #32012

Zig Version

0.17.0-dev.44+0177cb57c

Steps to Reproduce and Observed Behavior

Likely relevant issue: https://github.com/ziglang/zig/issues/24225 (about a person who had similar issues on Windows, while I happen to be on Linux. I also have experienced this bug for what feels like at least a year or so by now, which would match that person's experience)

System info:

$ uname -a
Linux nixos-laptop 6.18.22 #1-NixOS SMP PREEMPT_DYNAMIC Sat Apr 11 12:26:52 UTC 2026 x86_64 GNU/Linux
$ free -h
 total used free shared buff/cache available
Mem: 15Gi 7.8Gi 414Mi 939Mi 7.9Gi 7.4Gi
Swap: 15Gi 5.8Gi 10Gi

Using the zig2 compiler to build just about any Zig program (like pub fn main() void {}) seems to crash my Framework Laptop 13 (11th gen Intel model) fairly consistently (say, 40-60% of the time). For small programs, sometimes the build succeeds. Other times, it gives me a core dump that seems to be related to some AVX512 instructions. Otherwise, the laptop screen freezes and becomes unresponsive requiring me to force the power off, or sometimes I see a visually messed up dmesg-like screen for a while until the laptop automatically reboots.

This doesn't seem to be my hardware being stressed as I can easily compile LLVM from source and have not failed any programs meant to stress or test memory issues.

At this point, I'm suspecting that it's a CPU bug? I don't even think this is actionable on Zig's side (except maybe being able to figure out a more minimal reproduction than "use zig2"), but I figured it's worth reporting as a continuation to the issue linked above. I mean, zig2 is the only program that I know that triggers this issue, and it's damn consistent at triggering it.

Feel free to close it, but I kind of wanted to document this somewhere.

Expected Behavior

Ideally, this wouldn't happen and I can actually follow the build steps in this project's README, or use something like zig-bootstrap. This issue does make it a tad harder for me to attempt contributing because I have yet to successfully compile Zig using zig2. (In the end, I used a static stage3 binary in place of where zig2 ought to be used)

I think I'll try bootstrapping versions 0.15.0 and earlier until I can at least come up with a bisect of when this started.

$ lscpu
Architecture: x86_64
 CPU op-mode(s): 32-bit, 64-bit
 Address sizes: 39 bits physical, 48 bits virtual
 Byte Order: Little Endian
CPU(s): 8
 On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
 Model name: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
 CPU family: 6
 Model: 140
 Thread(s) per core: 2
 Core(s) per socket: 4
 Socket(s): 1
 Stepping: 1
 CPU(s) scaling MHz: 21%
 CPU max MHz: 4200.0000
 CPU min MHz: 400.0000
 BogoMIPS: 4838.40
 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse ss
 e2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopol
 ogy nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sd
 bg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdran
 d lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l2 cdp_l2 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow 
 flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdt_a avx512f avx512dq
 rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec x
 getbv1 xsaves split_lock_detect user_shstk dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
 hwp_pkg_req vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg 
 avx512_vpopcntdq rdpid movdiri movdir64b fsrm avx512_vp2intersect md_clear ibt flush_l1d arch_capabiliti
 es
Virtualization features: 
 Virtualization: VT-x
Caches (sum of all): 
 L1d: 192 KiB (4 instances)
 L1i: 128 KiB (4 instances)
 L2: 5 MiB (4 instances)
 L3: 8 MiB (1 instance)
NUMA: 
 NUMA node(s): 1
 NUMA node0 CPU(s): 0-7
Vulnerabilities: 
 Gather data sampling: Mitigation; Microcode
 Ghostwrite: Not affected
 Indirect target selection: Mitigation; Aligned branch/return thunks
 Itlb multihit: Not affected
 L1tf: Not affected
 Mds: Not affected
 Meltdown: Not affected
 Mmio stale data: Not affected
 Old microcode: Not affected
 Reg file data sampling: Not affected
 Retbleed: Not affected
 Spec rstack overflow: Not affected
 Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
 Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
 Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; PBRSB-eIBRS SW sequence; BHI SW loop, KVM SW lo
 op
 Srbds: Not affected
 Tsa: Not affected
 Tsx async abort: Not affected
 Vmscape: Not affected

It's not clear what you mean by zig2. How did you build?

I've definitely tried and failed with:
https://codeberg.org/ziglang/zig#building-from-source (using just cmake .. + make, and again with the flags from https://codeberg.org/ziglang/zig#editing-source-code)
https://codeberg.org/ziglang/zig-bootstrap (tried compiling with CMAKE_GENERATOR=Ninja ./build x86_64-linux-gnu baseline, not that the target matters as the build fails before the "cross-compilation" part, at build-zig-host)

I think I've tried and failed with these, hopefully not misremembering:
https://codeberg.org/ziglang/zig#building-from-source-without-llvm
zig-bootstrap with make, not passing CMAKE_GENERATOR=Ninja, again with x86_64-linux-gnu baseline. (I don't see why this wouldn't fail too, bar the build system being single-threaded)

All of these make a binary called zig2, starting with the zig1 Wasm seed, was it? I should double-check on the "without llvm" step to see if that one was problematic too.

Edit: looks like the zig2 built using bootstrap.c doesn't seem to error out, or crash my system (at least, it succeeded to compile a file 10 times in a row, which was unthinkable with the ones made using the cmake build system)

Me and another person have ran into this before https://github.com/ziglang/zig/issues/14508

The ruling at the time was that this is out of scope for Zig (even if nothing else is exhibiting this behavior) and with further debugging I concluded that this is a CPU/microcode bug, but who can you even report this type of issue to?

but who can you even report this type of issue to?

Last I looked, there doesn't seem to be a proper channel for this. It seems like the only thing you can do as a consumer, essentially, is to try to raise awareness of the bug and put pressure on Intel that way. So for most people, that's functionally identical to "there's nothing you can do". Convenient for Intel, isn't it?

Anyway, I'm closing this because realistically there's nothing we can do about it either.