Segmentation Fault in C: Common Causes and How to Fix It

An access arrow crosses a memory boundary toward a warning marker.

A segmentation fault in C usually means the program attempted an invalid memory access and the operating system stopped it. Start by examining the pointer, index, or destination used at the failing line.

The crash location is a hint, not necessarily the initial error. A previous out-of-bounds write can corrupt data that fails much later.

Common causes and the right repair

Mistake Example of invalid code Repair
Out-of-bounds index Accessing a[3] when a has three elements Keep the index nonnegative and below the element count
Null dereference Using *p when p == NULL Check allocation or lookup results before access
Uninitialized pointer Declaring int *p; and writing through it Point to a live object or allocate storage
Use after free Accessing an object after free(p) Keep accesses within the object's lifetime
Writing a string literal Modifying characters through a pointer to a literal Use a writable character array
Incorrect input destination Passing an integer value to scanf("%d", ...) Pass a pointer to an int, and check the conversion result

These invalid operations have undefined behavior. They are not guaranteed to cause a segmentation fault on every run or platform.

Fix an array-bound error

The valid indexes for an array of three elements are 0, 1, and 2. A loop condition such as i <= 3 lets the loop reach an invalid fourth access.

This corrected program calculates the count from the array and uses <:

#include <stdio.h>

int main(void)
{
    int values[] = {10, 20, 30};
    size_t count = sizeof values / sizeof values[0];

    for (size_t i = 0; i < count; ++i) {
        printf("values[%zu] = %d\n", i, values[i]);
    }

    return 0;
}

Output:

values[0] = 10
values[1] = 20
values[2] = 30

The sizeof calculation works because values is an actual array in this scope. A parameter declared as an array is adjusted to a pointer parameter; it does not carry the array's element count. Pass that count separately.

Check scanf's destination and result

The scanf function requires the address of an int object for %d. Here is a complete example that passes &value and tests to see if one conversion succeeded:

#include <stdio.h>

int main(void)
{
    int value = 0;
    printf("Enter a small integer: ");
    fflush(stdout);

    if (scanf("%d", &value) != 1) {
        fputs("Expected an integer.\n", stderr);
        return 1;
    }

    printf("You entered %d\n", value);
    return 0;
}

If you type in 7, it will display You entered 7. In this example, numeric input is assumed to be contained in an int. If you need to parse arbitrary or possibly very large numbers, use line input and a checked conversion like strtol.

Wiring in & everywhere is not a general solution. For instance, a character array passed with an appropriate string conversion already provides a pointer to the first element and string input requires a length limit.

Use a repeatable debugging process

  1. Save the exact input that causes the crash.
  2. Build with warnings and debug information.
  3. Find the first invalid access using a debugger or supported sanitizer.
  4. Inspect the object's size, lifetime, and initialization at that point.
  5. Fix the cause, then rerun the failing input and nearby boundary cases.

For a local Clang installation that supports AddressSanitizer:

clang -std=c17 -Wall -Wextra -g -O1 -fsanitize=address -fno-omit-frame-pointer main.c -o app
./app

Read the first reported invalid access and allocation/release information. A sanitizer can only test paths that you run; a clean run does not guarantee that all possible inputs are safe. Setup and platform support is described in the Clang AddressSanitizer guide.

What does “core dumped” mean?

On systems using this terminology, a core dump records process state that a debugger can use to investigate the crash. Whether a dump is retained, and where, depends on operating-system settings. Don't assume that a file called core always appears in the current directory.

Why does my program work on another computer?

Different symptoms may occur with a different compiler, optimization level, operating system, or memory layout, when undefined behavior occurs. If it was successful in another location, it does not mean that the original access was valid.

Can too much recursion cause a segmentation fault?

Yes, on many systems, it is possible to crash a program by exhausting the stack resources. Check the stopping condition and the input depth. Raising the stack size may delay failure, but will not fix unbounded recursion.

Run the corrected array example in the online C compiler. For related reasons, see arrays of pointers and dynamic allocation.

Related errors