SDB:Fehlerberichterstellung

Getestet mit openSUSE		Empfohlene Artikel		Verwandte Artikel
	13.2 13.1 12.3 12.2 12.1 11.4		SDB:Fehler berichten		SDB:YaST Fehler berichten

Fehler finden & Melden

Sie arbeiten gerade mit einer Anwendung und plötzlich passiert es - sie stürzt ab. Eine der Annehmlichkeiten von freier und quell offener Software ist die offene Gemeinschaft mit ihren Programmierern, die ihren Nutzern wirklich zuhören und versuchen, einen gemeldeten Fehler so schnell wie möglich zu beheben. So können Sie, als normaler Nutzer, Teil dieser Gemeinschaft werden, ganz einfach indem Sie Fehler melden und dann überprüfen ob die Korrekturen funktionieren.

Nur besteht das Melden eines Fehlers nicht einfach nur darin, zu sagen: "Es funktioniert nicht." Einer der Faktoren dabei, wie schnell ein Fehler beseitigt wird, ist die Art wie er gemeldet wird. Deshalb soll dieser kleine Leitfaden die Kommunikation zwischen Nutzern und Entwicklern bei der Problemlösung unterstützen.

Qualitäten guter Fehlerberichte

Verinnerlichen Sie bitte diese beiden Markenzeichen guter Fehlerberichte:

• Reproduzierbar: Versuchen Sie, den Fehler auf ihrem eigenen Rechner zu reproduzieren. Notieren Sie sich dabei jeden Schritt den Sie unternehmen um den Fehler hervorzurufen. Manchmal kann es hilfreich sein, im Hintergrund laufende Anwendungen auszuschalten, um Interaktionen zwischen dem abstürzenden Programm und Hintergrundprozessen auszuschließen. Wenn die abstürzende Anwendung mit einem anderen Prozess interagiert, dann sollte dass als Fehler berichtet werden. Jedes von ihnen gelieferte Detail hilft dem Techniker dabei, den Fehler auf seinem eigenen Rechner zu reproduzieren.

• Gezielt: Melden Sie pro Bericht nicht mehr als einen Fehler. Stellen Sie so genaue Informationen zur Verfügung wie Sie können. Schreiben Sie keine Dinge, die einen Programmierer oder Tester darin beeinflussen könnten, ihre Nachricht falsch zu verstehen.

Ein kleines Beispiel: Nehmen wir mal an, die fehlerhafte Anwendung ist ein Web-Browser. Er stürzt jedes mal ab, wenn Sie die Seite www.nullachtfünfzehn.de besuchen und Sie wollen nun einen Fehlerbericht schreiben:

SCHLECHT: "My browser crashed. I think I was on www.nullachtfünfzehn.de. I play golf with Bill Gates, so you better fix this problem, or I'll report you to him. By the way, your Back icon

looks like a squashed rodent. UGGGLY. Thx 4 UR help."

GUT: "The application crashed each time I went to

www.nullachtfünfzehn.de, using the 2006-04-01 build on a openSUSE system. It crashed again each time upon drawing the Foo banner at the top of the page. I broke apart the page, and discovered that the following image link will crash the application every time, unless you remove the
"BORDER=0" attribute:

<IMG SRC="" WIDTH="400" HEIGHT="44" BORDER="0" ALT="Our Banner">

Analysieren des Problems

Umgebung

Prüfen Sie als erstes ihre Rechnerumgebung. Notieren Sie die Systemversion, die Programmversion, eventuelle Erweiterungen (dazu noch deren Version) und so weiter. Danach versuchen Sie das Problem erneut hervorzurufen und notieren Sie sich dabei die Schritte die Sie machen um die Anwendung zum Absturz zu bringen. Schauen Sie, ob das Problem vielleicht in einer neueren Version der Software behoben wurde: Informieren Sie sich dazu auf der jeweiligen Projektseite.

-debuginfo-Pakete installieren

Die meisten Anwendungen mit grafischer Benutzeroberfläche (GUI) zeigen Ihnen nach einem Absturz eine Ablaufverfolgung. Eine Ablaufverfolgung (engl. backtrace) zeigt dem Entwickler genauer, wo der Fehler auftritt. Für gewöhnlich wird der GNU Debugger (GDB) dafür verwendet. Der GDB kann jedoch noch detailiertere Ablaufverfolgungen erstellen, wenn er über die entsprechenden Fehlersuchinformationen (debug infos) verfügt. Installieren Sie deshalb bitte das -debuginfo-Paket Ihrer Anwendung, um die Ausgabe des GDB zu verbessern. Diese Pakete sind nicht auf den Installations-CDs enthalten, sondern über die Quellen für die Internetinstallation im Verzeichnis "debug" auf unserem HTTP-Download-Server oder einem Spiegelserver verfügbar. Dieses Verzeichnis kann als Installationsquelle in YaST integriert werden.

• Debug-Paketdepot für die offiziellen openSUSE-Veröffentlichungen
• Debug-Paketdepot für Factory

Installieren Sie bitte die Pakete und versuchen Sie, den Absturz zu reproduzieren. Fügen Sie dem Fehlerbericht die Ablaufverfolgung und eine Beschreibung bei, wie Sie den Absturz hervorrufen. Diese Pakete helfen ebenso beim Finden von Fehlern, wenn Sie GDB direkt benutzen, wie Sie weiter unten sehen werden.

Fehler finden

Es existiert keine Aktualisierung und Sie können das Problem locker wieder hervorrufen. Nun ist es an der Zeit, die Anwendung auf Fehler zu untersuchen. Das Suchen und Finden von Fehlern kann eine Menge Zeit in Anspruch nehmen -- aber es ist manchmal der einzige Weg einen guten Fehlerbericht zu schreiben und so den Entwicklern dabei zu helfen, dass Problem schnell zu lösen.

Es gibt verschiedene Wege, eine Anwendung auf Fehler zu untersuchen; so müssen Sie sich jeden Weg anschauen und dann überlegen, welcher der richtige für ihre Anwendung ist.

strace

Programme benutzen oftmals Dateien um Konfigurationen einzulesen, auf Hardware zuzugreifen oder um Protokolle zu schreiben. Ab und zu versucht ein Programm, so eine Datei unvorschriftsmäßig zu erreichen. strace ist ein nützliches Diagnose-, Vorgehens- und Fehlersuchwerkzeug und kann bei dieser Art von Fehlern helfen. strace verfolgt Systemaufrufe zurück, die auf Arbeitsspeicher und Dateien zugreifen.

Im einfachsten Fall führt strace den angegeben Befehl aus, bis dieser beendet wird. Es fängt die Systemaufrufe eines Prozesses und die Signale die er erhält ab und zeichnet sie auf. Der Name jedes Systemaufrufs, seine Argumente und seine Rückgabewerte werden in die Standardausgabe oder in eine über die Option -o angegebene Datei ausgegeben.

Ein Beispiel für das stracing des Befehls cat /dev/null ist:

strace -f -ttt -o strace.log cat /dev/null

Hierbei wird eine Datei namens strace.log im aktuellen Verzeichnis erstellt. Wir überprüfen die Datei, die relevanten Teile sind unten aufgeführt:

open("/dev/null", O_RDONLY) = 3

Fehler (typischerweise ein Rückgabewert von -1) haben errno-Symbol und Fehlerzeichenkette angehängt.

open("/foo/bar", O_RDONLY) = -1 ENOENT (No such file or directory)

Strace ist deshlab meist der beste Weg, Anwendungen auf Fehler zu untersuchen, die während des Startens oder beim Öffnen oder Speichern von Dateien abstürzen.

GDB benutzen

GDB, der GNU Debugger, ist ein Programm um Laufzeitfehler zu finden, die normalerweise Arbeitsspeicherfehler beinhalten. Sie können ihn auch dazu verwenden, eine Rückverfolgung (engl. backtrace) durchzuführen, eine Sequenz von Funktionsaufrufen, die zu einem Absturz führt. Wenn Sie eine Rückverfolgung von /usr/bin/kaputtesprogramm, welches jedes mal beim Ausführen mit Speicherzugriffsfehlern um sich schmeißt, durchführen wollen, verwenden Sie das folgende Kommando:

$ gdb /usr/bin/kaputtesprogramm

GNU gdb 6.5

...

(gdb)

Sie befinden sich nun in GDBs eigener Eingabeaufforderung. Geben Sie run ein und warten Sie, bis das Programm abstürzt:

(gdb) run

Starting program: /usr/bin/kaputtesprogramm

Program received signal SIGSEGV, Segmentation fault.

0x08048394 in brokenfunc () at broken c:4

4 *i = 2

(gdb)

Alternativ können Sie sich, wenn das Programm bei der Anmeldung oder von einem init-Skript oder etwas ähnlichem gestartet wird, an den laufenden Prozess anhängen und warten, bis das Programm abstürzt:

$ pidof brokenprogram

12345

$ gdb /usr/bin/brokenprogram 12345

(gdb) continue

Continuing.

Program received signal SIGSEGV, Segmentation fault.

0x08048394 in brokenfunc () at broken.c:4

4 *i = 2;

(gdb)

Nun geht auf der GDB-Konsole weiter. Geben Sie nun backtrace ein.

(gdb) backtrace

1. 0 0x08048394 in brokenfunc () at broken.c:4
2. 1 0x080483a4 in somefunc () at segv.c:9
3. 2 0x080483ae in foobar () at segv.c:14
4. 3 0x080483c3 in main () at main.c:19

(gdb)

Speichern Sie diese Ausgabe und beenden Sie GDB mit quit.

Wenn ein Programm nur bei der Verwendung eines bestimmten Parameters abstürzt, sagen wir mal --crash, dann müssen Sie diesen Parameter dem run-Kommando hinzufügen:

(gdb) run --crash

Starting program: /usr/bin/kaputtesprogramm --crash

dmesg

Zur Fehleranalyse kann eine Ausgabe des Befehl:

$ dmesg

helfen, dieser zeigt oder kontrolliert den Kernel-Ring-Puffer. Wenn Sie also Probleme mit dem Kernel selbst oder Kernel-bezogenen Anwendungen (besonders Kernel-Module oder Hotplug-Zeug) haben, sollten Sie dieses Werkzeug verwenden.