Fix "Segmentation fault (core dumped)" on Linux

sudo apt update && sudo apt full-upgrade   # or: sudo dnf upgrade / sudo pacman -Syu
coredumpctl list
coredumpctl info -1

In the terminal, and in the kernel log:

Segmentation fault (core dumped)
Segmentation fault
myapp[51234]: segfault at 0 ip 00007f3a1c2b4e10 sp 00007ffd6b1c9a80 error 4 in libfoo.so.2[7f3a1c290000+40000]

What the error means

The program read or wrote a memory address it does not own (a null pointer, freed memory, past the end of a buffer, or a stack overflow). The CPU traps, the kernel sends SIGSEGV, and the process dies with exit status 139. "Core dumped" means a snapshot of its memory was saved so you can see exactly where it crashed. The kernel line is useful on its own: in libfoo.so.2 names the binary or library where the bad access happened, and segfault at 0 means a null pointer.

Step 1: read the core dump

Fedora and Arch store crashes with systemd-coredump by default; on Debian and Ubuntu install it with sudo apt install systemd-coredump (otherwise Ubuntu hands crashes to apport). Then list recent crashes and show the stack trace of the latest:

coredumpctl list
coredumpctl info -1

Example output:

           PID: 51234 (myapp)
        Signal: 11 (SEGV)
    Executable: /usr/bin/myapp
       Message: Process 51234 (myapp) of user 1000 dumped core.
                Stack trace of thread 51234:
                #0  0x00007f3a1c2b4e10 foo_parse (libfoo.so.2 + 0x24e10)
                #1  0x000055d0c1a2f3b1 main (myapp + 0x23b1)

The top frames tell you which component crashed. For full symbols, open it in gdb; Ubuntu, Fedora, Debian and Arch all run debuginfod servers, and gdb downloads symbols from them when it asks (answer y) as long as DEBUGINFOD_URLS is set, which current releases do by default:

coredumpctl gdb -1
(gdb) bt

If coredumpctl shows nothing on Ubuntu, apport may have captured the crash in /var/crash; also check ulimit -c, which is 0 in some shells. You can also find the kernel line with journalctl -k | grep segfault (see the journalctl cheat sheet).

Cause 1: a broken or mismatched package

A partial upgrade, an interrupted install, or mixing repositories (PPAs, third-party RPMs, an AUR package built against old libraries) leaves a program linked against a library version it was not built for. Update everything, then reinstall the package and the library from the backtrace:

# Debian / Ubuntu / Mint
sudo apt full-upgrade
sudo apt install --reinstall myapp libfoo2
# Fedora
sudo dnf distro-sync
sudo dnf reinstall myapp
# Arch (never partial-upgrade with -Sy)
sudo pacman -Syu
# openSUSE
sudo zypper dup     # Tumbleweed; on Leap: sudo zypper up

Check file integrity with sudo debsums -s (Debian/Ubuntu), rpm -Va myapp (Fedora/openSUSE) or pacman -Qkk myapp (Arch). If apt reports dependency problems while doing this, see held broken packages. On Arch, rebuild AUR packages after major library updates.

Cause 2: a corrupt config, cache or plugin

Many desktop apps crash on a corrupt settings file, a cache from an older version, or a third-party plugin or extension. Test with a clean profile by moving the config away (not deleting it):

mv ~/.config/myapp ~/.config/myapp.bak
mv ~/.cache/myapp ~/.cache/myapp.bak
myapp

If it works now, restore pieces of the old config until you find the bad one. Browsers have safe modes (firefox --safe-mode), and GNOME Shell extensions can be disabled with gnome-extensions disable <uuid>.

Cause 3: graphics drivers

When the backtrace ends in libGL, libEGL, libnvidia-*, libvulkan or a Mesa *_dri.so, the GPU driver stack is involved. Update Mesa or the NVIDIA driver, make sure the kernel module and userspace versions match (cat /proc/driver/nvidia/version versus the installed package) and reboot after driver updates. Flatpak apps bring their own GL runtime, so run flatpak update too.

Cause 4: bad RAM, overheating or overclocking

If unrelated programs crash at random places, or the compiler segfaults during big builds, suspect hardware. Signs: different crash addresses every time, crashes under load, kernel general protection fault or MCE messages in journalctl -k.

• Run memtest86+ for several passes (many distros include it in the GRUB menu, or install memtest86+).
• Disable XMP/EXPO memory profiles and CPU overclocks in firmware and retest.
• Check temperatures with sensors (package lm-sensors).

Cause 5: a bug in your own code

If you wrote the program, compile with debug info and sanitizers, which point to the exact line:

gcc -g -O0 -fsanitize=address,undefined -o myprog myprog.c
./myprog
# or run under valgrind
valgrind --leak-check=full ./myprog
# or gdb
gdb -ex run -ex bt --args ./myprog arg1

Classic causes: dereferencing NULL, writing past an array, using memory after free(), returning a pointer to a local variable, or deep recursion overflowing the stack (ulimit -s shows the stack limit). For Python, a segfault means a C extension crashed: run with python3 -X faulthandler script.py to see which module, and upgrade it.

Distro-specific notes

• Ubuntu: apport may intercept crashes and offer to report them; ubuntu-bug /var/crash/<file>.crash sends a report to Launchpad.
• Fedora: ABRT (abrt-cli list or the "Problem Reporting" app) collects crashes and can file reports with backtraces.
• Arch: enable debuginfod with the debuginfod package; the DEBUGINFOD_URLS variable is set automatically.
• Debian: install systemd-coredump if coredumpctl is missing; if gdb does not offer to download symbols, set export DEBUGINFOD_URLS="https://debuginfod.debian.net".

How to prevent it

• Keep systems fully updated and avoid partial upgrades and mixed repositories.
• Report reproducible crashes upstream with the coredumpctl info output; that is how they get fixed.
• If the process is simply disappearing with Killed rather than a segfault, it is a memory problem instead: see Out of memory: Killed process. For general diagnostics, see the troubleshooting field guide.

Frequently asked questions