Fix Linux Segmentation Fault in 3 Steps

30-Second Fix: Restart and Check Resources

This sounds dumb, but most segfaults are just your program hitting a memory wall. Before you do anything else:

Check free memory. Run free -h in a terminal. If you see zero available RAM, the system is starving. Kill something heavy: pkill -f firefox or whatever is eating it. Then try your program again.
Check disk space. Run df -h. If your root partition is 100% full, the kernel can't write a core dump (if you need it), and some programs crash. Delete old logs: sudo journalctl --vacuum-time=2d or sudo rm -rf /var/log/*.old. Then retry.
Restart the program. Not the whole machine—just the crashing process. Sometimes it was a one-time glitch. Do /path/to/your/program again. If it works now, you're done. If it crashes again, move to the next fix.

Real story: I had a user whose Python script segfaulted every morning. Turned out a cron job was filling /tmp to 100% overnight. After cleanup, the script ran fine. Start here.

5-Minute Fix: Update Software and Libraries

Old versions of programs or system libraries have bugs that cause segfaults. Updating often fixes it. Do this:

Update your system.
- Ubuntu/Debian: sudo apt update && sudo apt upgrade -y
- CentOS/RHEL: sudo yum update or sudo dnf upgrade --refresh
- Fedora: sudo dnf upgrade --refresh
After that, reboot if the kernel was updated: sudo reboot. Then test your program.
Update the program itself. If you compiled from source, rebuild it: cd /path/to/source && make clean && make && sudo make install. If it's from a package manager, reinstall: sudo apt install --reinstall your-program or sudo yum reinstall your-program.
Check for missing libraries. Run ldd /path/to/your-program. If any line says "not found", install that library. For example, if libssl.so.1.1 is missing, do sudo apt install libssl1.1 (Ubuntu) or sudo yum install openssl-libs (CentOS).

I've seen segfaults vanish after updating glibc or libstdc++. It's a cheap fix. Don't skip it.

15+ Minute Fix: Debug with GDB and Address Sanitizer

If the above didn't work, the crash is inside your program's code. You need to find exactly where. This takes longer, but it's the only way to fix a real bug.

Step A: Enable Core Dumps

First, make sure the system saves a core dump when the crash happens. Run:

ulimit -c unlimited

Then run your program until it crashes. A file named core (or core.1234) should appear in the current directory. If not, check sudo sysctl kernel.core_pattern — it might be in /var/lib/systemd/coredump/ nowadays.

Step B: Get a Backtrace with GDB

Install GDB if you don't have it: sudo apt install gdb or sudo yum install gdb.

Load the core dump into GDB:

gdb /path/to/your-program /path/to/core

Inside GDB, type:

bt

That gives a backtrace. Look for the last function call before the crash. It might say something like #0 0x00007f... in __strlen_avx2 () or #1 0x00005... in my_function () at myfile.c:42. The myfile.c:42 means line 42 in myfile.c is where it died. That's your clue.

If you don't see line numbers, your program was compiled without -g flag. Rebuild it with -g -O0 (slower but debuggable) and reproduce the crash again.

Step C: Use Address Sanitizer

If GDB leaves you scratching your head, recompile the program with Address Sanitizer (ASAN). It catches memory errors like buffer overflows, use-after-free, and stack smashes. Add these flags to your compiler:

CFLAGS="-fsanitize=address -fno-omit-frame-pointer -g"
LDFLAGS="-fsanitize=address"

Rebuild with make clean && make. Then run your program. When it crashes, ASAN prints a detailed report like this:

=================================================================
==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x...
WRITE of size 4 at 0x... thread T0
    #0 0x... in my_function /home/user/project/myfile.c:42
    #1 0x... in main /home/user/project/main.c:15
...
0x... is located 0 bytes to the right of 20-byte region ...

That tells you exactly: line 42 of myfile.c wrote past the end of a buffer. Fix that line — maybe you need malloc(24) instead of malloc(20), or you forgot to null-terminate a string.

Step D: Common Fixes by Crash Type

GDB/ASAN Output	Likely Fix
`__strlen` or `__memcpy` in backtrace	Your code passed a NULL pointer or garbage to a string function. Check all pointer arguments before calling `strlen()`, `strcpy()`, etc.
`heap-buffer-overflow`	You wrote past the end of a malloc'd buffer. Increase buffer size by at least 1. Or fix loop boundaries.
`use-after-free`	You accessed memory after `free()`. Set pointers to NULL after freeing: `ptr = NULL;`. Check for double free too.
`stack-buffer-overflow`	You wrote past a local array, like `char buf[10]` and then `buf[10] = 0`. Use `strncpy()`, `snprintf()`, or check indices.
`SIGSEGV` with no backtrace	Stack overflow (too deep recursion) or corrupted stack. Reduce recursion depth, or increase stack size with `ulimit -s 65536`.

Step E: Still Stuck? Narrow It Down

If the backtrace is in a library you don't control (like OpenSSL or libpng), you might have found a library bug. Compile the library yourself with ASAN, or try an older/newer version. If it's your own code, add printf statements before the crash line to see variable values. Something like:

printf("DEBUG: x=%d, ptr=%p\n", x, ptr);

I had a case where a segfault only happened when a config file had an empty line. A simple printf showed me the parser was reading a NULL string. Fixed in two minutes.

That's it. Start with the 30-second fix, then the 5-minute update, then go deep with GDB and ASAN. Most crashes are solved by step 1 or 2. But when they aren't, the debug steps above will get you to the line of code responsible.