Bericht: Vortrag "Debuggen mit Strace" am 16.03.04

[Peter Voigt]

Hallo allerseits,

ich möchte von dem Treffen der Lug Owl von Montagabend berichten:

Wer kennt das nicht: Ein Linux-Programm läuft nicht so, wie es eigentlich 
sollte. Und die Ursache ist unbekannt.

Helfen Manpages und Änderungen der Aufrufparameter nicht weiter, sind Tools 
gefragt, die tiefere Einblicke ermöglichen.

An dieser Stelle kommt strace ins Spiel. Weil der Einsatz von strace keine 
besonderen Vorkehrungen benötigt, kann jedes Programm untersucht werden. 

Darin unterscheidet sich strace von Debuggern. Ihr Einsatz ist sinnvoll, falls 
das zu untersuchende Programm dafür vorbereitet ist. 

Programme, die von kommerziellen Firmen stammen, enthalten selten 
Debbuging-Informationen. Solche Firmen lassen sich eben nicht so gerne in die 
Karten schauen. 

(Unter Linux kann man das aber nicht wirklich verhindern. Das stellte sich an 
diesem Abend heraus).

Strace gewährt im Regelfall keinen Einblick in die Semantik eines Programmes. 
Dafür setzt man Disassembler ein. Das Diassemblieren ist aber aufwendig und 
setzt Kenntnisse der Maschinenprogrammierung voraus. 

Deshalb sind häufig lstrace oder strace das Mittel der Wahl.

Ltrace geht einen Schritt weiter als strace. Ltrace listet alle internen 
Funktionsaufrufe, strace nur die Betriebssystemaufrufe. Ltrace arbeitet daher 
genauer, erzeugt aber auch viel mehr Output bis hin in den Megabyte-Bereich. 
Das Mehr an Informationen verstellt mitunter den Blick auf das eigentlich 
Wichtige. Deshalb startet man am besten mit strace. 

Strace spiegelt das Geschehen an der Schnittstelle zwischen Programm und 
Betriebsystem wieder. In vielen Fällen erlaubt dieses Geschehen einen 
Rückschluß auf die Funktionsweise des fraglichen Programmes.

Versucht das Programm beispielsweise, eine nicht nicht vorhandene Datei zu 
öffnen, könnte es daran liegen, dass das Programm im falschen Verzeichnis 
sucht. Und das könnte daran liegen, dass das Programm im falschen Verzeichnis 
gestartet oder der Suchpfad in der Variablen PATH falsch gesetzt wurde.

Solche Schlüsse zu ziehen, sind das tägliche Brot beim Einsatz von strace. 
Dafür bietet strace eine Fülle von Ausgangsinformationen. Man kann genau 
erkennen, wann und wie welche Dateien, Bibliotheken, Betriebssystemfunktionen 
und dergleichen benutzt werden. 

Ist man sich darüber im Klaren, wie das fragliche Programm prinzipiell 
funktionieren müßte, kann man die Stelle, an der es hakt, lokalisieren. So 
werden Rückschlüsse auf Fehlerursachen möglich.

Wie man dabei systematisch vorgeht, war Thema des Vortrages von Jan-Benedict 
Glaw. In seiner überaus kompetenten Art beleuchtete er das Thema von allen 
Seiten.

Ausgehend von der Funktionsweise von strace definierte er den Einsatzraum und 
die Grenzen der Erkenntnismöglichkeiten, um sodann anhand mehrerer Beispiele 
die Vorgehensweise bei der Analyse praktisch vorzustellen. 

Das typische Ablaufmuster eines Linux-Programmes, beginnend mit dem Aufruf 
über die Shell, das Allozieren des Hauptspeichers, das Laden des 
Programmcodes, das Nachladen der benötigten Libraries, das Einbinden von 
Eingabe- und Ausgabeprozeduren, das Nutzen von Files und Hardwarekomponenten 
stellte JBG anhand der strace-Ausgaben so plastisch dar, das es leicht 
nachzuvollziehen war.

Detailiert ging JBG darauf ein, wie die Ausgabe von strace zu interpretieren 
ist, welche Rückschlüsse auf das zu untersuchenden Programmes möglich und wo 
weitere Informationen im Linuxsystem zu finden sind. 

Am Schluß zeigte sich, dass mit der Beobachtung einer Handvoll 
Betriebssystemaufrufe über strace das Geschehen an der Schnittstelle zwischen 
Betriebssystem und Programm sehr genau erfaßt werden kann (vgl. angehängte 
Liste).

Mit der entsprechenden Option von strace oder durch den Einsatz von grep kann 
die Datenfülle erheblich reduziert werden, so dass nichts mehr von der 
Analyse ablenkt. 

Die Zuhörer zu dieser Erkenntnis zu führen, ohne sie zu überfordern und ohne 
sich durch die vielen Fragen von seinem roten Faden ablenken zu lassen, 
zeichnet den Vortragsstil von JBG aus. Die Fülle seiner praktischen Tipps 
werden manchen Zuhörer stundenlanges Suchen und Grübeln ersparen.

Und so ganz nebenbei und völlig unauffällig gewannen die Zuhören einen tiefen 
Einblick in das interne Geschehen von Linux. So hat JBG an diesen Abend zwei 
Fliegen mit einer Klappe geschlagen.

Kein Wunder, dass die Diskussion erst mitten in der Nacht endete.

Dank der Organisation von Thomas Balls-Thies stand  ein Computerraum im ZiF 
zur Verfügung. Bei dem Zif handelt es sich um ein der Universität Bielefeld 
angegliedertes Institut. Die Atmosphäre des Zif's eignet sich für einen 
solchen Vortrag perfekt.

Ich erlaube mir, im Namen aller Teilnehmer zu sprechen, wenn ich beiden für 
ihren gelungenen Einsatz gratuliere.

Grüße
Peter Voigt
--------------------------------------------------------------------
Liste der wichtigsten Betriebssystemfunktionen, die beispielsweise über 
strace -e trace=........ (alternativ mit Hilfe von grep .......)
gefiltert werden können:

open/close
Datei öffnen/schließen

read/write/send/recv/sendto/recvfrom
Lesen/Schreiben von/an einen Datei-Descriptor

mmap
Datei-Bereiche im Speicher sichtbar machen

fork
Programm duplizieren

exec
Ein anderes Programm starten;  das ehemalige Programm geht dabei "seinen 
letzten Gang"

exit
Programm beenden, Return-Wert hinterlassen

stat/fstat/lstat
Datei-Eigenschaften (Größe, Device Node?, ...) abfragen

pipe
Kommunikations-Kanal (Strohhalm mit zwei Enden) erstellen

dup2
Gezielt einen Datei-Descriptordurch einen anderen ersetzen

wait
Kindesleichen wegräumen (sonst gibt's Zombies)

socket
Netzwerk-"Henkel" erzeugen

connect
 Ziel für Netzwerk-Verbindung festlegen

bind/listen/accept
(Serverseitig) Verbindungen annehmen

poll/select
Prüfen, ob von einem Datei-Descriptor Daten gelesen werden können.