Segmentierungsfehler in C: Ursachen und Behebung

Segmentation fault (core dumped)

Diese eine Zeile ist der meistgesuchte Fehler in C, und sie ist weniger rätselhaft, als sie aussieht. Dein Programm hat den Prozessor nach einer Speicheradresse gefragt, das Betriebssystem hat geprüft, ob dein Prozess diese Adresse anfassen darf, und die Antwort war nein. Der Kernel hat den Prozess dann mit einem SIGSEGV-Signal beendet.

Die wichtige Erkenntnis: Der Absturz ist ein Symptom, und sein Ort ist oft nicht der Bug. Der schlechte Zeiger entstand meist woanders, früher, und das ist bloß die erste Stelle, an der er benutzt wurde. Diese Seite behandelt die fünf Ursachen, die fast jeden Segfault erklären, und dann die zwei Werkzeuge, die die echte Zeile in Sekunden finden.

Die abstürzenden Beispiele unten sind bewusst keine lauffähigen Blöcke - sie stürzen absichtlich ab. Lies sie, und lies dann die korrigierte Fassung, die folgt.

Was „Speicher, der dir nicht gehört" bedeutet

Wenn dein Programm startet, bildet das Betriebssystem mehrere Bereiche in seinen Adressraum ab: den Code, die globalen Variablen, den Stack und das, worauf der Heap gewachsen ist. Alles andere im Adressraum - einschließlich der Adresse 0 - ist nicht abgebildet. Fass eine nicht abgebildete Adresse an oder schreibe in eine nur lesbare, und die Hardware fängt es ab.

Ein Segfault ist also nicht der Compiler, der dich erwischt. Es ist eine Leitplanke zur Laufzeit, und sie greift nur, wenn die ungültige Adresse zufällig außerhalb deiner abgebildeten Seiten liegt. Deshalb kann derselbe Bug auf einer Maschine abstürzen und auf einer anderen zu funktionieren scheinen: Das Speicherlayout unterscheidet sich.

Ursache 1: einen NULL-Zeiger dereferenzieren

Die häufigste Ursache und die am leichtesten zu behebende. Adresse 0 ist nie abgebildet, ein Lese- oder Schreibzugriff über einen Nullzeiger scheitert also immer.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    int *p = NULL;
    *p = 42;              /* ABSTURZ: Schreiben an Adresse 0 */
    printf("%d\n", *p);
    return 0;
}

Die realistische Fassung ist eine ungeprüfte Belegung:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    int *data = malloc(1000000000000UL * sizeof(int));  /* scheitert, liefert NULL */
    data[0] = 1;                                        /* ABSTURZ */
    free(data);
    return 0;
}

malloc liefert NULL, wenn es die Anfrage nicht erfüllen kann; ebenso fopen, wenn die Datei nicht existiert, und strchr, wenn das Zeichen fehlt. Prüfe jede Funktion, die NULL liefern kann, bevor du ihr Ergebnis benutzt.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    int *data = malloc(10 * sizeof *data);
    if (data == NULL) {
        fprintf(stderr, "Belegung fehlgeschlagen\n");
        return 1;
    }

    for (int i = 0; i < 10; i++) {
        data[i] = i * i;
    }
    printf("data[9] = %d\n", data[9]);

    free(data);
    return 0;
}

Initialisiere Zeiger mit NULL, statt sie uninitialisiert zu lassen. Ein Nullzeiger stürzt sofort und offensichtlich ab; ein Müllzeiger kann etwas beschädigen und viel später abstürzen. Mehr zu dem Muster unter Nullzeiger.

Ursache 2: über das Ende eines Arrays hinausschreiben

C prüft keine Arraygrenzen. Index 10 eines Arrays mit 10 Elementen ist schlicht der Speicher hinter dem Array, und der Compiler berechnet diese Adresse kommentarlos für dich.

#include <stdio.h>

int main(void) {
    int arr[10];

    for (int i = 0; i <= 10; i++) {   /* <= statt < : einer zu viel */
        arr[i] = i;
    }

    printf("fertig\n");
    return 0;
}

Ob das abstürzt, ist Glückssache. Vier Bytes hinter ein lokales Array zu schreiben landet meist auf anderen Stackdaten - einem gesicherten Register, einer anderen Variablen, der Rücksprungadresse -, das Programm beschädigt sich also selbst und stürzt später an einer unverwandten Stelle ab. Eine große Überschreitung verlässt die abgebildete Seite und erzeugt sofort einen Segfault.

Die wildere Fassung stürzt immer ab:

#include <stdio.h>

int main(void) {
    int arr[10];
    arr[1000000] = 42;      /* weit außerhalb von allem Abgebildeten: ABSTURZ */
    return 0;
}

Die Lösung ist die Gewohnheit i < n und n zu berechnen, statt es zweimal zu tippen:

#include <stdio.h>

int main(void) {
    int arr[10];
    size_t n = sizeof arr / sizeof arr[0];

    for (size_t i = 0; i < n; i++) {
        arr[i] = (int)(i * i);
    }

    for (size_t i = 0; i < n; i++) {
        printf("%d ", arr[i]);
    }
    printf("\nsicher %zu Elemente gefuellt\n", n);
    return 0;
}

Zeichenketten haben ihre eigene Fassung davon: ein Puffer ohne Platz für das abschließende '\0'.

#include <string.h>

int main(void) {
    char name[5];
    strcpy(name, "Alexander");   /* 9 Zeichen + Terminator in 5 Bytes */
    return 0;
}

strcpy hat keine Ahnung, wie groß name ist. Nimm snprintf, das es weiß, weil du es ihm sagst:

#include <stdio.h>

int main(void) {
    char name[5];

    snprintf(name, sizeof name, "%s", "Alexander");
    printf("Sicher gekuerzt: '%s'\n", name);
    return 0;
}

Ursache 3: einen Zeiger nach free benutzen (baumelnde Zeiger)

Nach free(p) geht der Speicher an den Allokator zurück. Der Zeiger hält weiterhin die alte Adresse, aber diese Adresse gehört dir nicht mehr.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    int *p = malloc(sizeof *p);
    *p = 42;
    free(p);

    printf("%d\n", *p);   /* Use-after-free: kann Müll ausgeben, kann abstürzen */
    free(p);              /* doppeltes Freigeben: bricht meist ab oder zerstört den Heap */
    return 0;
}

Die verwandte Falle ist, die Adresse einer lokalen Variablen zurückzugeben. Ihr Stackrahmen ist in dem Moment fort, in dem die Funktion zurückkehrt:

#include <stdio.h>

int *make_number(void) {
    int value = 42;
    return &value;      /* der Rahmen stirbt hier; der Zeiger baumelt */
}

int main(void) {
    int *p = make_number();
    printf("%d\n", *p);   /* undefiniert: Müll oder ein Absturz */
    return 0;
}

Zwei Lösungen, je nachdem was du meintest. Gib den Wert statt eines Zeigers zurück, oder belege auf dem Heap und lass den Aufrufer freigeben:

#include <stdio.h>
#include <stdlib.h>

int *make_number(int v) {
    int *p = malloc(sizeof *p);
    if (p != NULL) {
        *p = v;
    }
    return p;                 /* Heap-Speicher ueberlebt die Funktion */
}

int main(void) {
    int *p = make_number(42);
    if (p == NULL) {
        return 1;
    }

    printf("%d\n", *p);

    free(p);
    p = NULL;                 /* jetzt stuerzt eine spaetere Nutzung laut ab, nicht still */

    if (p == NULL) {
        printf("Zeiger sicher geleert\n");
    }
    return 0;
}

Den Zeiger direkt nach free auf NULL zu setzen ist die billige Schutzgewohnheit: Sie verwandelt ein stilles Use-after-free in einen sofortigen, offensichtlichen Absturz durch Null-Dereferenzierung, und sie macht ein zweites free(p) harmlos, da free(NULL) definiert nichts tut. Die Belegungsseite dieser Geschichte steht unter dynamischer Speicher und Speicherlecks.

Ursache 4: Stacküberlauf durch entgleiste Rekursion

Jeder Funktionsaufruf legt einen Rahmen auf den Stack, und der Stack ist ein Bereich fester Größe (üblicherweise 8 MB). Rekursion ohne Basisfall - oder mit einem, der nie erreicht wird - läuft über sein Ende hinaus.

#include <stdio.h>

int countdown(int n) {
    printf("%d\n", n);
    return countdown(n - 1);    /* kein Basisfall: hört nie auf */
}

int main(void) {
    return countdown(5);
}

Dasselbe passiert mit einem Basisfall, über den die Rekursion hinwegschreitet:

int f(int n) {
    if (n == 0) return 1;
    return n * f(n - 2);    /* von einem ungeraden n aus nie gleich 0 */
}

Jede rekursive Funktion braucht einen Basisfall, der von jeder Eingabe aus erreichbar ist:

#include <stdio.h>

long factorial(int n) {
    if (n <= 1) {           /* <= faengt 0, 1 und negative Werte ab */
        return 1;
    }
    return n * factorial(n - 1);
}

int main(void) {
    for (int i = 0; i <= 10; i++) {
        printf("%d! = %ld\n", i, factorial(i));
    }
    return 0;
}

Ein riesiges lokales Array schafft es auch - int buffer[10000000]; innerhalb einer Funktion fordert 40 MB Stack an und scheitert beim ersten Schreibzugriff. Belege große Puffer mit malloc auf dem Heap. Siehe Stack gegen Heap für die beteiligten Größen und Rekursion für den Entwurf von Basisfällen.

Ursache 5: in ein Zeichenkettenliteral schreiben

Das überrascht die Leute, weil der Code harmlos aussieht.

#include <stdio.h>

int main(void) {
    char *s = "hallo";
    s[0] = 'H';          /* ABSTURZ: Zeichenkettenliterale sind nur lesbar */
    printf("%s\n", s);
    return 0;
}

Ein Zeichenkettenliteral liegt in einem nur lesbaren Abschnitt der ausführbaren Datei. char *s = "hallo" zeigt hinein; über diesen Zeiger zu schreiben ist ein Schutzverstoß, den das Betriebssystem genauso als Segfault meldet wie einen Zugriff auf nicht abgebildeten Speicher.

Die Lösung ist, ein Array zu nehmen, das seine eigene änderbare Kopie bekommt:

#include <stdio.h>

int main(void) {
    char s[] = "hallo";      /* ein Array, aus dem Literal kopiert */
    s[0] = 'H';
    printf("%s\n", s);

    const char *fixed = "welt";   /* const sagt: schreib nicht hierdurch */
    printf("%s\n", fixed);
    return 0;
}

Literalzeiger als const char * zu deklarieren verwandelt diesen Laufzeitabsturz in einen Übersetzungsfehler, was schlicht besser ist. Mach es zur Gewohnheit.

Die echte Zeile finden: gdb

Kompiliere mit -g, damit die ausführbare Datei Debug-Symbole trägt, und lass sie dann unter dem Debugger laufen:

gcc -g program.c -o program
gdb ./program

In gdb:

(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x0000555555555151 in process_item (item=0x0) at program.c:14
14          return item->count * 2;

(gdb) backtrace
#0  process_item (item=0x0) at program.c:14
#1  0x000055555555518a in main () at program.c:23

(gdb) print item
$1 = (struct Item *) 0x0

Drei Befehle erledigen den Großteil der Arbeit. run startet das Programm und hält dort an, wo es scheitert. backtrace (oder bt) zeigt die Kette der Aufrufe, die dorthin führten - Rahmen #1 ist meist der Ort, an dem der schlechte Zeiger tatsächlich entstand. print inspiziert eine Variable, und item = 0x0 benennt das Problem rundheraus.

Unter macOS ist das Gegenstück lldb ./program, dann run und bt.

Es schneller finden: AddressSanitizer

Besser noch: Lass den Compiler das Programm instrumentieren. AddressSanitizer fängt den ungültigen Zugriff in dem Moment ab, in dem er passiert - auch die, die nicht abgestürzt wären:

gcc -g -fsanitize=address program.c -o program
./program

==12345==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000000010
WRITE of size 4 at 0x602000000010 thread T0
    #0 0x4011f6 in main program.c:11

0x602000000010 is located 0 bytes inside of 4-byte region
freed by thread T0 here:
    #1 0x4011c9 in main program.c:10
previously allocated by thread T0 here:
    #2 0x4011a6 in main program.c:8

Dieser Bericht benennt die Fehlerklasse, die Zeile, die es tat, die Zeile, die den Speicher freigab, und die Zeile, die ihn belegte. Es ist das wirksamste Debugging-Werkzeug für Speicherfehler in C, es funktioniert mit GCC und clang unter Linux und macOS, und es kostet grob die doppelte Laufzeit - was während der Entwicklung belanglos ist.

Paare es mit -fsanitize=undefined, um gleichzeitig vorzeichenbehafteten Überlauf und anderes undefiniertes Verhalten abzufangen:

gcc -g -Wall -Wextra -fsanitize=address,undefined program.c -o program

valgrind ./program ist die Alternative, die keine Neuübersetzung braucht und dieselben Fehlerklassen plus Lecks meldet.

Eine Checkliste, wenn du auf einen triffst

1. Baue neu mit -g -Wall -Wextra -fsanitize=address,undefined und lass es erneut laufen. Meist benennt der Bericht die Zeile und du bist fertig.
2. Ist der Sanitizer nicht verfügbar, lass es unter gdb laufen und nimm ein backtrace. Sieh dir Rahmen 1 an, nicht nur Rahmen 0.
3. Prüfe jeden Zeiger in der abstürzenden Zeile. Gib jeden aus; 0x0 kennzeichnet einen Nullzeiger, und ein wilder Wert wie 0x7fff5fc01000 bedeutet meist uninitialisiert oder freigegeben.
4. Frage, woher dieser Zeiger kam. Ein ungeprüftes malloc oder fopen? Die Adresse einer Lokalen, deren Funktion längst zurückgekehrt ist? Ein Zeiger, der nach free benutzt wurde?
5. Prüfe jede Schleifengrenze nahe dem Absturz auf ein <=, wo < gemeint war.
6. Ist die Aufrufkette Tausende Rahmen tief, ist es entgleiste Rekursion und überhaupt kein Zeigerfehler.

Sie verhindern

Die Gewohnheiten, die Segfaults selten machen:

• Kompiliere immer mit -Wall -Wextra und behandle Warnungen als Bugs.
• Initialisiere jeden Zeiger, mit NULL, wenn nichts Besseres da ist.
• Prüfe den Rückgabewert von malloc, calloc, realloc und fopen.
• Setze Zeiger unmittelbar nach dem Freigeben auf NULL.
• Nimm snprintf und fgets statt sprintf und gets.
• Deklariere Zeiger auf Zeichenkettenliterale als const char *.
• Bevorzuge sizeof arr / sizeof arr[0] gegenüber einer fest eingetragenen Länge.
• Lass die Testsuite in der CI unter AddressSanitizer laufen.

Ein Segfault ist die freundliche Fehlerart - er sagt dir, dass etwas nicht stimmt. Dieselbe Fehlerklasse, die still eine benachbarte Variable beschädigt und drei Funktionen später falsche Antworten erzeugt, ist weit schlimmer, und die obigen Werkzeuge fangen beides ab.