Segementation Fault unter Linux/Mac debuggen

Für die Uni muss ich ja nun viel C schreiben, und da gibt es ja nun mal diese wunderbaren Pointer. Sollte man davon mal eine falsch setzen bricht das Programm ab, und es gibt eine wunderbare Fehlermeldung: Segementation Fault: 11. Jetzt heißt es also, den Fehler mit jede Menge printf() eingrenzen und nach sehr viel Suchen dann evtl. auch finden.

Nach den ich heute mal wieder einen Pointer falsch hatte, habe ich mal nachgesehen, ob es nicht auch einfacher geht… Geht es natürlich… Also eine kleine Anleitung! Ich habe extra für euch ein Programm mit Fehler gebaut: Sowas würde mir sonst natürlich nie passieren 😉

Was nun? Als ersten müssen wir dem Betriebsystem sagen, dass es einen Speicherdump (coredump) erstellen soll, wenn ein Programm abstürzt. Die Dinger werden ziemlich groß, deswegen ist das normalerweise ausgeschaltet. Um es für die akutelle Shell zu aktivieren geben wir ulimit -c unlimited ein. Damit wird bei nächsten Absturz ein core-dump erstellt. Damit kommen wir schon recht weit, doch wir können das Programm noch im Debug-Modus kompilieren, damit wir noch besser sehen, was da schief gelaufen ist. Dazu einfach gcc den Parameter -g mitgeben (ja, clang kann das auch). Danach lassen wir das Programm wieder abstürzen:Na, aufgepasst? Da steht jetzt (core dumped). Nun schauen wir mal in den Ordner /cores, dort liegt unser core dump! Und er ist (für dieses einfache Programm) >300 MB groß! Das war das, was ich oben meinte…

Nun können wir das Programm mit gdb laden, und sehen genau die Stelle, an der unser Programm abgestürzt ist! (Befehl: gdb [programm] [core]
Ohne weitere Parameter sehnen wir schon die Funktion, Datei und Zeile (!) in der das Programm uns verlassen hat, mit list bekommen wir ein bisschen Kontext, und mit print [variable] kann man sich sogar alle Variablen ausgeben lassen! Hier ist p = 0x0, also ein Pointer auf NULL.

Das ist wahnsinnig praktisch, ich weiß gar nicht, warum ich nicht vorher nach sowas gesucht habe… Sicherlich haben IDEs wie Eclipse (oder natürlich Visual Studio) deutlich bessere Debugger direkt im Code etc., aber sowas ist schon ein ziemlicher unterschied zu gar keinem Debugger… Und das ohne eine dicke IDE drum herrum, nur auf der Console… Ich glaube, ich muss mir gdb mal etwas näher ansehen 😀

Ich hoffe, das hilft dem einem oder anderen Kommilitonen bei gewissen Übungsblättern 😉

3 Gedanken zu „Segementation Fault unter Linux/Mac debuggen

  1. Also ich muss ja jetzt NUR noch C programmieren. Ich würde dem gcc nur den Parameter -g übergeben, damit er ein debug-Binary erstellt und das Programm dann direkt im gdb starten:
    gdb –args [argumente]
    r (für run)
    Beim segfault bleibt das ganze dann auch hängen und man kann mit backtrace nachsehen, wo das war. Mit n steppt man Zeile für Zeile durch, mit b : oder b setzt man Haltepunkte, mit c läuft man bis zum nächsten Haltepunkt, mit n eine Zeile weiter, mit p kann man sich werte anzeigen lassen, mit display werden diese in jedem Schritt angezeigt, mit backtrace sehe ich den Aufrufstack und mit up kann ich in diesem nach oben wechseln…
    usw…. ein Corefile braucht man bei der Entwicklung nicht.
    Wer’s graphisch mag: ddd statt gdb verwenden für eine wunderhübsche tk-Oberfläche.

    1. Oho, hoher Besuch hier im Blog 🙂

      Du hast natürlich Recht, wenn man es sich genau überlegt sind die Core-Files wohl eher dafür gedacht, wenn ein Fehler bei jemanden ohne Debugger auftritt. Wenn er einem das Core-File gibt, kann man den Fehler dann trotzdem suchen…

      Aber wenn ich nur noch C schreiben würde, dann würde ich wirklich mal über eine IDE nachdenken… gdb mag ja ganz nett sein, aber ich hab mein VisualStudio (oder von mir aus auch Eclipse, etc.) wirklich schätzen gelernt 😀

      1. Wenn du auf einem Entwicklungsserver mit komplexer Infrastruktur debuggen musst, dann führt kaum ein Weg an gdb vorbei, denn der Rechner auf dem das läuft (und laufen muss), der hat ja keine graphische Oberfläche (ja, man kann gdb auch im Server-Modus aus Eclipse heraus fernsteuern, aber das ist mir dann auch zu umständlich).
        Für das Entwickeln an sich nutze ich Eclipse ja auch…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.