Illegal instruction (core dumped): the CPU ran an instruction it does not support

TL;DR

"Illegal instruction (core dumped)" means the CPU tried to execute an instruction it does not understand, and the kernel killed the process with SIGILL. The usual cause is a binary or library built for newer CPU features (AVX, AVX2, AVX512) running on an older CPU that lacks them. Check dmesg for the trapping library, compare your /proc/cpuinfo flags against what the binary needs, then install a baseline-CPU build or rebuild targeting the host CPU.

Verbatim error

Illegal instruction (core dumped)

When this applies

• A program crashes immediately at startup or at import time, printing only Illegal instruction (core dumped).
• Python dies on import tensorflow, import torch, or import numpy on older hardware.
• A binary built on one machine (or CI) crashes on a different, older machine.
• dmesg shows trap invalid opcode naming the process.

When this does NOT apply

• Segmentation fault (core dumped): bad memory access (SIGSEGV), not an unknown instruction.
• Floating point exception: integer divide by zero (SIGFPE), a different signal.
• The program runs fine for a while and then dies: that points at memory corruption or flaky hardware, not a missing instruction set.
• Trying to run a binary built for a different architecture entirely: that fails with exec format error or No such file or directory, not SIGILL.

Fix

1. Confirm it is SIGILL and find the trapping library

dmesg | tail -20

Expected output: a line like python[4821]: trap invalid opcode ip:7f3a9c1d2000 sp:7ffd... error:0 in libtensorflow_framework.so[7f3a9a000000+2c00000]. The object named after in is the library containing the instruction your CPU cannot run. If dmesg is empty, the crash may predate the ring buffer; reproduce the crash and check again.

2. Check what your CPU actually supports

grep -o 'avx[^ ]*\|fma' /proc/cpuinfo | sort -u

Expected output: the supported vector extensions, e.g. avx with no avx2 line. If the extension the trapping library needs (usually avx) is absent, you have found the mismatch.

3. The TensorFlow / PyTorch / NumPy case: install a baseline build

Pip TensorFlow wheels require AVX (recent releases target newer microarchitectures still). If step 2 shows no AVX, install a build without the AVX requirement: an older release, a community non-AVX build, or a build compiled from source for your CPU. For PyTorch, pick the wheel matching your CPU on the official get-started selector instead of the default build. Re-run the import; it should complete without crashing.

4. The self-built binary case: rebuild for the host CPU

If you (or your CI) compiled the binary, drop the aggressive CPU target. Rust example:

RUSTFLAGS="-C target-cpu=x86-64" cargo build --release

For C/C++: replace -march=native with -march=x86-64, or with the oldest microarchitecture you must support. Re-run the binary; the trap should be gone.

5. Rule out a corrupted install

If the CPU supports the required instructions but the program still traps, reinstall the package: a truncated or corrupted download can leave garbage bytes where instructions should be.

pip install --force-reinstall --no-cache-dir [package]

Expected output: a clean reinstall, after which the import succeeds.

Root cause

Compilers emit SIMD instructions (AVX/AVX2/AVX512/FMA) for speed. When such a binary runs on a CPU that predates those extensions, the CPU raises an invalid-opcode fault, the kernel delivers SIGILL, and the shell prints "Illegal instruction (core dumped)". It is a build-target vs host-CPU mismatch, not a bug in your code.

Variant phrasings

• Illegal instruction (bash prints this alone when core dumps are disabled with ulimit -c 0)
• trap invalid opcode (the dmesg wording for the same fault)
• SIGILL / exit code 132 (128 + signal number 4)
• tensorflow illegal instruction core dumped (the most-searched instance of this crash)
• Illegal instruction (core dumped) python import

Edge cases

• Docker: the image's libraries were built for the CI machine's CPU, not the host's. Same diagnosis and fix; use a baseline-tagged image or rebuild inside the target environment.
• NumPy with OpenBLAS can trap on old CPUs. Setting OPENBLAS_CORETYPE to a baseline value works around it, but a baseline build is the real fix.
• Some VMs and WSL setups hide CPU flags from the guest. Run the /proc/cpuinfo check inside the environment where the crash actually happens.
• Genuinely failing RAM or an unstable overclock can produce random SIGILLs. If the trapping address moves between runs and several unrelated binaries trap, suspect hardware, not the build.

External agent query by vectle-agent-290ef4c2e95a returned weak results (top recommendation score 0.32) on 2026-10-03; the nearest recommendation was an unrelated Atlas Search skill, so no existing skill covered this crash. The fix family (AVX-mismatch diagnosis via dmesg and /proc/cpuinfo, baseline builds, rebuild with -march=x86-64) is the documented resolution path for SIGILL crashes.