Kernel-Crash-Analyse unter Linux

Analyse mittels gdb

Die generierte Crash-Datei kann mit den Standard-Tools unter Linux untersucht werden. Als Voraussetzung dafür gilt allerdings die Installation der entsprechenden Debug-Pakete des Kernels. Der Name und die Verfügbarkeit ist je nach Distribution unterschiedlich. So heißen beispielsweise die Pakete unter RHEL 5.4 kernel-debug und kernel-debuginfo. Sie sind nicht in der Standarddistribution enthalten und müssen separat aus dem debuginfo-Verzeichnis der Distribution heruntergeladen werden. Unter OpenSuse 11.3 heißt der Kernel dagegen kernel-<type>-debuginfo. Wichtig ist in allen Fällen, dass die Version der Debug-Informationen zum laufenden Kernel passt.

Sind die Pakete installiert, kann es an die eigentliche Untersuchung gehen. Im Falle von RHEL dürfte das Kommando wie folgt aussehen:

gdb \
/usr/lib/debug/lib/modules/<kernel>/vmlinux \
vmcore

Wichtig ist bei diesem Schritt, dass dem Tool neben der korrekten Crash-Datei auch die sich auf Datei beziehende Kernel-Objektdatei übergeben wird. Unter OpenSuse sehen die Parameter wie folgt aus:

gdb \
/usr/lib/debug/boot/<kernel>.debug \
vmcore

Alternativ können anstelle von gdb auch artverwandte Tools wie gdbtui oder ddd eingesetzt werden. Die Parameter unterscheiden sich in der Standarddistribution nicht. So kann beispielsweise der grafische Debuger ddd mit denselben Optionen wie gdb gestartet werden.

Analyse mittels crash

Mag gdb noch so mächtig sein, liegen seine Einsatzbereiche nicht unbedingt in der Untersuchung von Kernel-Problemen. Oftmals ist neben dem eigentlichen Code auch die Umgebung oder der Status des Systems von besonderer Bedeutung für die Lösung eines Kernel-Problems. Nicht selten führen Fehler in einem Subsystem zu Fehlern in einem anderen, beispielsweise Speicherprobleme, in denen Module ihnen nicht zugewiesenen Speicher überschreiben.

Die Crash-Datei enthält noch weit mehr Informationen. Neben dem Abbild des Speichers sind in der Datei auch Log-Informationen, Prozessdaten, Interrupts und Dateisysteminformationen enthalten. Dies all soll nur dem einzigen Zweck dienen – der schnellen Untersuchung und Korrektur von Fehlern.

Sichtbar gemacht werden können die Crash-Informationen mittels des Tools »crash«. Crash erlaubt nicht nur, den Status des Systems während, sondern auch nach einem Crash zu untersuchen. Dabei kommt das Programm mit zahlreichen Crash-Formaten klar. Unter anderem vermag es Dumps von netdump, diskdump, kdump oder xendump darzustellen. Die Grundlagen von crash liegen dabei im crash-Kommando von System System V Release 4 (SVR4), das allerdings nicht nur auf Linux portiert, sondern auch massiv angepasst wurde. Die wohl größte Änderung gegenüber dem Original stellt die Integration des gdb dar. So ist es mittels crash möglich, die Techniken des Ur-Tools und die des Quellcode-Debuggers in einem Tool zu nutzen.

Der Aufruf von crash gleich dem von gdb. So lässt sich das Tool unter RHEL beispielsweise mittels folgenden Kommandos ausführen:

crash \
/usr/lib/debug/lib/modules/<kernel>/vmlinux \
vmcore

Arbeiten mit crash

Streng genommen verfügt crash über vier verschiedene Arten von Kommandos. Zum einen enthält es Befehle, die Kernel-Daten oder Text darstellen. Die wohl wichtigsten davon sind »struct« und »union« gepaart mit »*«, die Kernel-Datentypen darstellen. Ferner unterstützt crash auch die Anzeige von Kernel-Variablen mittels »p« und von Symbolen mittels »whatis«. Das Kommando »sym« übersetzt dagegen einen Symbolnamen in eine virtuelle Adresse. »dis« dagegen disassembliert eine Kernel-Funktion.

Informationen des Tools »crash« samt Kernel-Stacktrace

Mirko Lindner

Informationen des Tools »crash« samt Kernel-Stacktrace

Der zweite Bereich von crash umfasst zahlreiche Tools, die sich dem Status des Systems widmen. Neben »bt«, das einen Kernel-Stack anzeigt und damit wohl das erste Kommando einer jeder Untersuchung darstellt, bietet es auch Kommandos zur Anzeige von Geräten, Dateien, Benutzerinformationen, Prozessor- und Prozessdaten, Mount- und Netzwerk-Optionen oder Speicherdaten. Im Grunde genommen existieren nur wenige Bereiche, die sich dem Tools entziehen können. So können beispielsweise mittels der Kommandos »dmesg« oder »log« im Klartext die Loginformationen des Systems oder mittels »ps« der Prozessbaum angezeigt werden.

Der dritte Bereich von crash beinhaltet Werkzeuge, die eine Untersuchung erleichtern sollen. So können beispielsweise mittels »btop« physikalische Adressen in Page-Nummern oder mittels »ascii« numerische Werte in ASCII-Komponenten umgewandelt werden. Als besonders mächtig erweist sich hier das »wr«-Kommando, das in der Lage ist, in einem laufenden System Speicherbereiche zu ändern. Voraussetzung hierfür ist allerdings ein Schreibzugriff auf /dev/mem. In einem Crash-Dump ist das Kommando selbstverständlich Sinn- und Funktionslos.

Schlussendlich bietet crash auch zahlreiche Kommandos zur Sessionskontrolle. Mittels »alias« können Aliase definiert werden. »q« oder »exit« dagegen beenden das Tool.

Abschließend

Wie bei allen Fehlern kann auch unter Linux keine Garantie für eine fehlerfreie Funktionsweise eines Crash-Dumps gegeben werden. Betrachtet man den Umstand, dass ein Dump durch einen fatalen Fehler erzeugt wurde, besteht immer noch die Möglichkeit, dass die im Abbild enthaltenen Daten keine Rückschlüsse auf die Quelle des Problems zulassen.

Doch trotz allem sind Crash-Dumps, sei es bei Applikationen oder im Kernel, eine wertvolle Quelle, um Probleme schnell zu identifizieren und zu lösen. Die Wahrscheinlichkeit, einen Fehler mittels einer Crash-Dump-Analyse im Kernel wenigstens einzugrenzen, ist ungleich höher als durch eine Beschreibung. Denn die meisten Fehler des Kernels oder eines Treibers geschehen nicht durch ein systematisches Problem, sondern durch ein Fehlverhalten eines Subsystems, ein Timingproblem oder schlicht Defekte in der Hardware. Diese lokal zu reproduzieren ist für einen Entwickler, der womöglich an einem Treiber nur in seiner Freizeit schreibt, schier unmöglich.