Segmentation fault, explained and diagnosed

A segmentation fault (SIGSEGV, often printed as Segmentation fault (core dumped)) means a process tried to read, write, or execute memory that is not mapped for it, and the kernel terminated it on the spot. Unlike most errors on this site, the user at the keyboard did not cause it and cannot configure it away: it is a defect in the program's native code, a corrupted installation, an incompatible library, or, when many unrelated programs start crashing, failing hardware. The useful work is identifying which of those it is, with evidence.

Gather the evidence

  1. Note exactly which program and action triggers it, and whether it is repeatable on demand or random. Deterministic crashes on one action point at the program; random crashes across many programs point at the machine.
  2. Read the kernel's record: dmesg | tail (or journalctl -k) shows the faulting address and instruction pointer; a fault at a near-zero address is the classic null-pointer bug in the program, while varying addresses across crashes suggest something less deterministic.
  3. Check the core dump: coredumpctl on systemd systems lists captured cores; opening one with gdb program core and running bt shows the function stack at the crash, which is what a bug report needs and often names the responsible library.
  4. Test the hardware if crashes are widespread: a memory tester (Memtest86+ from a boot menu) run for several passes, plus disk health checks. RAM faults manufacture segfaults in innocent programs, and no amount of reinstalling fixes them.

The causes, in order of likelihood

  1. A bug in the program or one of its libraries, most often; updating to a fixed release, or reporting with the backtrace, is the path. A crash that began after a program update and affects that program alone sits here.
  2. A mismatched or corrupted installation: partially upgraded libraries (a program loading a mix of old and new), fixed by completing the upgrade or reinstalling the package cleanly.
  3. Overclocked or failing hardware, RAM first, when the crashes are random, multi-program, and resistant to reinstalls.
  4. Running a binary built for different assumptions (wrong architecture libraries forced onto the loader path, hand-set LD_LIBRARY_PATH pointing at incompatible libraries) in self-assembled setups.
There is no user-side “fix the segfault” setting, and tools claiming to repair random crashes are not a real category. The honest options are updating or reinstalling the program, rolling back a bad update, gathering a backtrace for the developers, or proving and replacing bad hardware.

Common questions

What does “core dumped” add? It records that the kernel saved the process's memory image for debugging. That file is how developers (and you, with gdb) see exactly where it crashed; it is evidence, not additional damage.

Why does the same program crash on one machine and not another? Different library versions, different data, or different hardware. A crash tied to one input is a program bug; a crash tied to one machine across inputs is that machine's libraries or hardware until proven otherwise.

Can a Python or Java program segfault? Their runtimes are native programs, so yes, through native extensions, JNI libraries, or runtime bugs; pure managed code alone almost never does. The fault then lives in the native layer named in the crash log (hs_err_pid files for the JVM).

Related errors

Kernel panic: not syncing · StackOverflowError (Java) · Broken pipe (Linux)