What Is a Segmentation Fault

What the message means

When you run a broken C or C++ program on Linux or macOS, the terminal may print something like "Segmentation fault" and the program stops. No result, no explanation.

The name comes from how operating systems protect memory. Each running program is given its own areas of memory to use. If it reaches for an address outside those areas, or tries to write somewhere it may only read, the processor raises a fault and the operating system steps in.

On Linux, the operating system then sends the program a signal called SIGSEGV. The signal(7) manual page lists it as "Invalid memory reference," with a default action of "Core," which it defines as terminating the process and dumping core, meaning writing a snapshot of the program's memory to a file for debugging. The core(5) manual page lists several situations in which no core file is produced, such as the process lacking permission to write it, so you may not see one.

Why C++ programs segfault

A segmentation fault is an operating system event, not a rule of C++. What C++ has instead is a category called undefined behavior. The cppreference.com page on it says there are "no restrictions on the behavior of the program," and lists examples that include memory accesses outside of array bounds and null pointer dereference.

"No restrictions" is the important part. When your code does one of these things, the C++ standard does not say what happens. Often the program crashes with a segfault. Sometimes it prints a strange value and carries on. Sometimes it seems to work perfectly, until you change compiler settings or run it on another machine.

The three causes beginners meet most often:

1. Using a null pointer

A pointer holds the address of some other value. A null pointer holds no address at all. Reading through it, called dereferencing, is undefined behavior.

#include <iostream>

int main() {
    int* p = nullptr;        // p points at nothing
    std::cout << *p << '\n'; // undefined behavior: reading through a null pointer
}

Compiled with GCC and run on our test machine, this program stopped with "Segmentation fault." Learn C++ says that dereferencing a null pointer will crash your application in most cases, and calls null and dangling pointers "probably the most common reason" C++ programs crash in practice.

C++ Game: Segfault

Teaches C++ to complete beginners as a game where you tap one real line of code at a time.

Get it on Google Play

Free to play. Halls 1 to 4 are free with no time limit, and free players can watch optional rewarded video ads for bonuses. Segfault Pro, a monthly subscription or a 3-month pass paid once, opens hall 5 and up, unlimited practice sets and mock exams, with no ads.

Segfault takes its name from this error, but it starts much earlier: you tap one real C++ line at a time and watch the value change, which builds the habit of tracking exactly what each box holds.

2. Reading past the end of an array

Array positions in C++ start at 0. An array of three numbers has positions 0, 1 and 2. Asking for position 3, or 5, reaches outside it. With a plain array, or with std::vector and square brackets, nothing checks this for you, and the result is undefined behavior. A small mistake might read a neighbouring value; a large one is more likely to hit memory the program does not own and segfault.

The safer option while learning is the at member function of std::vector. According to cppreference.com, it checks the position and throws an exception of type std::out_of_range if it is outside the container, instead of silently reading bad memory:

#include <iostream>
#include <stdexcept>
#include <vector>

int main() {
    std::vector<int> scores {10, 20, 30};

    try {
        std::cout << scores.at(5) << '\n'; // checked: throws instead of reading past the end
    } catch (const std::out_of_range&) {
        std::cout << "index 5 is out of range\n";
    }
}

This prints "index 5 is out of range" and exits normally, because the mistake was caught at the exact line where it happened.

3. Using a dangling pointer

A dangling pointer still holds an address, but the thing it pointed to no longer exists, for example because it was a local variable inside a function that has already returned, or memory that was already freed. Learn C++ groups this with null pointers: using either is undefined behavior.

How to find the line that caused it

A segfault message rarely tells you where the problem is. A few tools help:

• Turn on warnings. Compile with -Wall -Wextra in GCC or Clang. The compiler cannot catch every memory error, but it warns about many suspicious patterns, such as returning the address of a local variable.
• Use a sanitizer. Clang and GCC both support AddressSanitizer. You compile with the -fsanitize=address flag, and the program then reports out-of-bounds accesses, use-after-free errors and more. The GCC manual recommends adding -g as well for more meaningful output. The Clang documentation says the typical slowdown is about 2x, so it is for testing, not for the version you ship.
• Use a debugger. Compile with -g to include debugging information and run the program under a debugger such as GDB. When it stops, the backtrace command (or bt) prints a summary of how the program got there, one line per function call, starting from the one that was running.
• Print as you go. For small programs, printing values before the crash often shows which index or pointer went wrong.

How to avoid segfaults as a beginner

Most come from a small set of habits:

1. Initialise every variable and pointer. Use nullptr for a pointer that does not point anywhere yet, and check it before use.
2. Check your loop limits. For an array of size 3, the loop condition should stop before 3, not at it. Off-by-one loops are a classic cause.
3. Prefer std::vector and std::string to raw arrays and C strings. They manage their own memory.
4. Use at while learning when an index comes from user input or a calculation.
5. Do not return the address of a local variable from a function.
6. Change one thing at a time and run the program often, so when it crashes you know what you just changed.

Is a segfault always my fault

In beginner programs, almost always yes, and that is good news: it means the cause is in code you can read. Keep in mind that the absence of a segfault does not prove your program is correct. Because undefined behavior has no rules, a program that reads one place past an array can run fine today and crash tomorrow. The goal is not code that happens not to crash; it is code that never touches memory it does not own.

For a broader plan of what to learn first, see how to learn C++ as a beginner.