¿Qué es un segmentation fault (fallo de segmentación)?

Un programa en C imprime su primera línea y luego se detiene con un mensaje que nadie escribió:

#include <stdio.h>

int main(void) {
    int *score = NULL;

    printf("About to read the score\n");
    printf("Score: %d\n", *score);
    return 0;
}

About to read the score
bash: line 1: 64030 Segmentation fault: 11  ./seg

Esa salida es de bash en macOS, donde 64030 es el ID del proceso y 11 es el número de la señal. En Linux el mismo fallo suele verse como Segmentation fault (core dumped) (en un sistema en español, "Violación de segmento (core generado)"). En cualquier caso, el programa nunca imprimió la puntuación. score contiene la dirección 0, y *score le pide al procesador que lea la memoria de esa dirección, algo que ningún programa tiene permitido.

Cómo se produce un segmentation fault

Cada programa se ejecuta en su propio espacio de direcciones virtual, un rango enorme de direcciones que el sistema operativo va rellenando por partes. Mapea en ese rango el código del programa, sus variables globales, su pila y su heap, en bloques llamados páginas (4 KB en la mayoría de los sistemas Linux x86, 16 KB en los Mac con Apple silicon). La mayoría de las direcciones quedan sin mapear, y la dirección 0 siempre está entre ellas para que se detecten los bugs de punteros nulos.

1. El programa ejecuta una instrucción que lee o escribe una dirección. Aquí es la lectura de *score, la dirección 0.
2. La unidad de gestión de memoria del procesador busca la dirección en la tabla de páginas. La página no está mapeada, o el programa intenta escribir en una página de solo lectura.
3. El procesador detiene la instrucción y cede el control al kernel con un fallo de página.
4. El kernel comprueba si el acceso podría ser legal, por ejemplo una pila que necesita crecer. No lo es, así que el kernel envía al proceso la señal 11, SIGSEGV.
5. La acción por defecto de SIGSEGV es terminar el proceso y, cuando el sistema lo permite, guardar un volcado de memoria (core dump). Después el shell imprime el mensaje y fija el código de salida en 139, que es 128 más el número de la señal.

Así que un segmentation fault no lo notifica el compilador, y no es una excepción que lance el lenguaje. Es el hardware y el kernel protegiendo la memoria, lo que lo convierte en un error en tiempo de ejecución del tipo más abrupto. Windows trata el mismo suceso como una access violation, con el código de excepción 0xC0000005.

Causas comunes de los segmentation faults

C y C++ permiten que un programa calcule cualquier dirección y la use, así que todas las causas se reducen a usar una dirección que no es válida.

• Desreferenciar un puntero nulo. int *p = NULL; *p = 5; Una función que devuelve NULL cuando falla, como malloc o fopen, lleva aquí cuando no se comprueba su resultado.
• Un índice mucho más allá del final de un array. C no comprueba los límites, así que arr[1000000] es simplemente una dirección un millón de elementos más adelante.
• Usar memoria después de free. El puntero sigue guardando la dirección antigua, pero la memoria ya no te pertenece.
• Un puntero sin inicializar. int *p; *p = 5; escribe a través del valor basura que tenga p en ese momento.
• Desbordamiento de pila. Una función recursiva sin caso de parada sigue añadiendo marcos de pila hasta salirse del final de la pila. El ejemplo de abajo falló en macOS con Segmentation fault: 11 y código de salida 139.
• Escribir en un literal de cadena. char *name = "coddy"; name[0] = 'C'; intenta cambiar memoria de solo lectura. En Linux eso es un segfault. En macOS el mismo programa se detuvo con Bus error: 10, una señal relacionada.

#include <stdio.h>

int depth(int n) {
    return depth(n + 1) + 1;   /* never stops calling itself */
}

int main(void) {
    printf("%d\n", depth(0));
    return 0;
}

Un fallo pequeño muchas veces no provoca ningún cierre, y eso lo hace más peligroso. Este bucle lee un elemento más allá del final de un array de tres elementos:

#include <stdio.h>

int main(void) {
    int scores[3] = {72, 88, 95};
    int total = 0;

    for (int i = 0; i <= 3; i++) {   /* <= reads scores[3] */
        total += scores[i];
    }
    printf("Total: %d\n", total);
    return 0;
}

Compilado con Clang en un Mac, imprimió Total: 256. El total correcto es 255. scores[3] eran los 4 bytes siguientes de la pila, que pertenecían al programa, así que no hubo fallo y el valor basura se sumó en silencio. El sistema operativo solo detiene los accesos a memoria que no pertenece en absoluto al programa.

La solución para ambos fallos es el mismo hábito: saber cuántos elementos hay y comprobar un puntero antes de seguirlo.

#include <stdio.h>

/* Returns a pointer to the highest score, or NULL if there are none. */
int *find_best(int *scores, int count) {
    if (count == 0) {
        return NULL;
    }
    int *best = &scores[0];
    for (int i = 1; i < count; i++) {
        if (scores[i] > *best) {
            best = &scores[i];
        }
    }
    return best;
}

int main(void) {
    int scores[3] = {72, 88, 95};
    int *best = find_best(scores, 3);
    int *none = find_best(scores, 0);
    if (best != NULL) printf("Best: %d\n", *best);
    if (none == NULL) printf("No scores, nothing to read\n");
    return 0;
}

Best: 95
No scores, nothing to read

Qué significa "core dumped"

Un volcado de memoria (core dump) es un archivo que guarda una copia de la memoria del programa en el momento en que falló. Un depurador puede abrirlo después y mostrar exactamente dónde estaba el programa y qué contenían sus variables: gdb ./app core. En muchas distribuciones de Linux, systemd-coredump recoge estos archivos, y coredumpctl list los muestra. Cuando los volcados de memoria están desactivados, por ejemplo con ulimit -c 0, el mensaje es solo Segmentation fault, sin las palabras entre paréntesis.

Cómo encontrar la línea que falló

La línea donde el programa se cae muchas veces no es la línea que tiene el bug. Un puntero puede volverse inválido en una función y usarse en otra mucho después. Estas herramientas muestran ambas cosas.

Un depurador. Compila con información de depuración y ejecuta el programa dentro del depurador. Cuando se detenga, bt (backtrace) imprime la cadena de llamadas a funciones con nombres de archivo y números de línea. En Linux el depurador suele ser gdb; en macOS es lldb, donde bt funciona igual.

gcc -g app.c -o app
gdb ./app
(gdb) run
(gdb) bt

AddressSanitizer. Compila con -fsanitize=address (GCC y Clang lo admiten) y ejecuta el programa con normalidad. En lugar de un segfault sin más, imprime un informe que nombra el tipo de fallo, como heap-use-after-free o stack-buffer-overflow, con la línea que hizo el acceso y la línea que reservó la memoria. También detecta la lectura silenciosa de un elemento de más del ejemplo anterior, que por sí sola nunca provoca un cierre.

Valgrind. En Linux, valgrind ./app ejecuta un programa sin modificar y notifica cada lectura o escritura inválida, como Invalid read of size 4.

Segmentation faults en otros lenguajes

Python, Java y JavaScript comprueban cada índice y cada referencia antes de usarlos, así que los mismos fallos se convierten en excepciones con mensajes claros: IndexError o AttributeError en Python, ArrayIndexOutOfBoundsException o NullPointerException en Java, TypeError en JavaScript. Esas se pueden capturar con el manejo de excepciones. Un segfault no se puede manejar así: es una señal, y un bloque catch de C++ no la ve.

Los programas en Python aún pueden dar un segfault cuando falla el código C que tienen debajo. Esta línea le pide a ctypes que lea la dirección 0:

import ctypes
ctypes.string_at(0)

Ejecutado con python3 -X faulthandler, Python 3.12 imprimió Fatal Python error: Segmentation fault, seguido de las líneas de Python que se estaban ejecutando. El mismo fallo ocurre cuando una extensión en C o una biblioteca nativa tiene un bug de memoria. Rust sigue otro enfoque: su compilador rechaza, antes de construir el programa, la mayor parte del código que podría acceder a memoria inválida.

Qué leer después

La guía de C sobre segmentation faults repasa cada causa con un programa mínimo y su solución. Para evitar los fallos desde el principio, lee sobre punteros, punteros nulos y la pila y el heap, y después practícalos en el curso de C. Para ver cómo se notifican los errores en los lenguajes que comprueban la memoria por ti, consulta la página de error en tiempo de ejecución.