GDB Debugging C++: Segfault in Minuten finden

GDB: Schritt-für-Schritt C++-Debugging ohne Segfault-Furcht

GDB zeigt dir innerhalb von 15 bis 30 Sekunden genau auf, wo dein Programm abstürzt. Statt wild Print-Ausgaben zu verteilen und immer wieder neu zu kompilieren, nutze den Debugger, um den Aufrufstapel und die aktuellen Variablenwerte in Echtzeit zu prüfen. Kompiliere mit -g -O0, um Debug-Informationen einzubinden:

g++ -g -O0 -o myprogram myprogram.cpp

Überprüfe mit file myprogram, ob die Debug-Info vorhanden ist. Starte die Fehlersuche mit gdb ./myprogram, dann führe run aus. Bei einem Segfault hält GDB an und zeigt die genaue Position mittels backtrace (bt).

Ein Absturz in std::string::operator= mit einem null-Pointer für this erscheint sofort im Stacktrace:

#0 0x... in std::string::operator= (this=0x0, ...)
#1 0x... in UserData::setName (...)
#2 0x... in main ()

Aktiviere lesbare Ausgabe: set print pretty on und set print demangle on.

Breakpoints und Schrittweise Durchführung des Codes

Setze Breakpoints, um die Ausführung zu steuern:

• break main — am Anfang von main
• break program.cpp:42 — an einer bestimmten Zeile
• break UserData::setName — beim Betreten einer Methode
• info break — alle Breakpoints auflisten

Bei überladenen C++-Funktionen musst du die Signatur angeben: break print(int) oder break print(std::string). Fortgeschritten: rbreak ^.*::print$, um alle Methoden namens print per Regex zu finden.

Navigiere durch den Code:

| Befehl | Kurzbefehl | Aktion |

|--------|------------|--------|

| next | n | Zeile ausführen, ohne in Funktionen einzusteigen |

| step | s | Zeile ausführen und in Funktionen eintauchen |

| finish | fin | Bis zum Ende der Funktion laufen |

| continue | c | Weiterlaufen bis zum nächsten Breakpoint |

In C++ solltest du step nicht in STL-Aufrufe wie push_back verwenden — nutze stattdessen next, um im eigenen Code zu bleiben.

Untersuchung von Variablen und Objekten

Verwende diese Befehle, um Daten zu prüfen:

• print variable_name — Wert der Variablen anzeigen
• print *pointer — Zeiger dereferenzieren
• print vec.size() — Methode aufrufen
• display variable_name — automatisch nach jedem Schritt anzeigen
• info locals — lokale Variablen anzeigen
• info args — Funktionsargumente anzeigen

GDB zeigt C++-Typen korrekt an:

print myVector
$1 = std::vector der Länge 5, Kapazität 8 = {1, 2, 3, 4, 5}

print myString
$2 = "Hello, World!"

Wenn du <optimized out> siehst, kompiliere erneut mit -O0. Ohne -g erscheinen keine Variablennamen.

TUI-Modus für visuelles Debugging

Aktiviere tui enable — der Bildschirm teilt sich: Oben wird der Quellcode mit der aktuellen Zeile hervorgehoben, unten erscheinen die Befehle. Verwende:

• layout src — Quellcode-Ansicht
• layout asm — Assembler-Ansicht
• layout split — Quellcode + Assembler
• layout regs — Register-Fenster
• Ctrl + X, 2 — zwei Fenster
• Ctrl + X, o — zwischen Fenstern wechseln
• Ctrl + X, a — TUI-Modus verlassen

Der TUI-Modus vereinfacht die Navigation, da Kontext direkt sichtbar ist – ohne Zahlen zu zählen.

Häufige Probleme und Lösungen

| Problem | Lösung |

|--------|--------|

| <optimized out> | Mit -O0 neu kompilieren |

| Keine Variablennamen | -g-Flag verwenden |

| Lokale Variablen fehlen | Innerhalb der Funktion info locals ausführen |

| Vector zeigt Müll | Bei älterer libstdc++: print vec._M_impl._M_start verwenden |

Wichtige Befehle für mittelständische Entwickler

Beherrsche diese 10 Befehle für 90 % aller Debugging-Aufgaben:

• r — starte Programm
• b — setze Breakpoint
• bt — Rückverfolgung (Backtrace)
• n — nächster Schritt
• s — Schritt in Funktion
• fin — bis zum Ende der Funktion
• c — weiterlaufen
• p — drucke Variable
• i locals — lokale Variablen anzeigen
• q — beende GDB

Wichtige Erkenntnisse

• Aufrufstapel (bt) löst 70 % der Segfaults in Sekunden und zeigt den vollen Weg zurück zur main.
• TUI-Modus visualisiert den Code und reduziert die mentale Belastung bei komplexen Projekten.
• -g -O0 sind Pflicht; ohne sie ist Debugging wirkungslos.
• next vs step ist entscheidend in C++ mit STL — vermeide tiefes Eintauchen in Bibliothekscode.
• display und info locals/args geben volle Sicht auf den Zustand, ohne den Code mit Print-Befehlen zu belasten.

— Editorial Team