Wiki » Fehlersuche bei Softwareabstuerzen

Warnung!

Das Wiki ist umgezogen und befindet sich nun unter https://wiki.mageia.org/en/Hauptseite-de . Bitte nutzen Sie das neue Wiki.

Die hier enthaltenen Informationen werden nicht aktualisiert und sind deshalb veraltet oder sogar falsch!
Diese Seite befindet sich im neuen Wiki hier: https://wiki.mageia.org/en/Fehlersuche_bei_Softwareabst%C3%BCrze-de

Weitere Sprachen

Deutsch ; English

Zurück zum Portal der Fehlertruppe

Diese Seite ist dazu bestimmt, dir zu helfen nützliche Informationen zu sammeln, wenn ein Absturz einer Anwendung auftritt, und möglicherweise von dir selbst zu beheben ist.

Einleitung

Zuerst solltest du die -debug Pakete der Anwendungen installieren und all die Bibliotheken die hier eingebunden sind. Dies ermöglicht es dir, mit Hilfe der ganzen Werkzeuge zur Fehlersuche, sehr nützliche Informationen anzuzeigen.

gdb selbst gibt eine handliche Liste der fehlenden -debug Pakete zurück, die noch zu installieren sind. Anschließend musst die diese fehlenden -debug-Pakete installieren und gdb neu starten. Nun kannst du nützliche Informationen sammeln indem du die nachfolgenden aufgelisteten Werkzeuge verwendest.

Damit es möglich ist die -debug Pakete, die du benötigst, zu installieren, musst du die separaten -debug Repositorys hinzufügen und aktivieren. Wenn du einen vollen Satz an Repositorys mittels der Mageia Softwareverwaltung hinzugefügt hast, ist alles was du tun musst, diese als root in einem Terminal mit folgendem Kommando zu aktualisieren:

 urpmi.update --no-ignore debug

gdb

Das Programm gdb ist der GNU Debugger. Stürzt ein Programm wegen eines Segmentfehlers oder eines Abbruchs ab, so erlaubt dir gdb eine Rückverfolgung durchzuführen. D.h. zu jener Stelle im Programm zu gehen, an der dieser Fehler aufgetreten ist.

Ausführen deiner Anwendung in gdb

Wenn du den Absturz leicht reproduzieren kannst, dann kannst du deine Anwendung innerhalb von gdb ausführen und nützliche Informationen erhalten, wenn der Absturz auftritt.

• Starte gdb, gib den Pfad zu deiner Anwendung ein und übergib, falls nötig noch die benötigten Parameter.

$ gdb /bin/cat 
GNU gdb 6.3-7mdv2007.0 (Mandriva Linux release 2007.0)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-mandriva-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".

(gdb)run /proc
Starting program: /bin/cat /proc
/bin/cat: /proc: Is a directory

Program exited with code 01.
(gdb)

• Erhältst du eine Meldung über Signal 33, so musst du gdb mitteilen, hier nicht zu stoppen und dies an die Anwendung zu übergeben und diese dann neu zu starten:

Program received signal SIG33, Real-time event 33.
[Switching to Thread 1182845264 (LWP 11543)]
0x00002b661d87d536 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) handle SIG33 nostop noprint noignore pass
Signal        Stop      Print   Pass to program Description
SIG33         No        No      Yes             Real-time event 33
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) run

• Wenn dann die Anwendung abstürzt befindest du dich an einer Eingabeaufforderung von gdb. Hole die Rücklaufverfolgung mit dem Kommando bt full, dies ist die Information, die wir im Fehlerbericht benötigen. Spricht die vorhergehende Meldung über threads, solltest du alle Rückverfolgungen mit thread apply all bt full erhalten.

(gdb) bt full
#0  0x00002b526953c7ef in poll () from /lib64/libc.so.6
No symbol table info available.
#1  0x00002b52691f412e in g_main_context_iterate (context=0x51f2d0, block=1, dispatch=1, 
self=Variable "self" is not available.) at gc:2977
max_priority = 2147483647
timeout = 30000
some_ready = Variable "some_ready" is not available.

gdb mit einer core-Datei ausführen

Kannst du, aus welchen Gründen auch immer den Absturz innerhalb von gdb nicht leicht reproduzieren, aber auf eine core-Datei zurückgreifen, so kannst du eine Analyse nach Absturz der Anwendung (post-mortem) ausführen. So z.B.:

$ gdb /bin/cat core.42

dann erhältst du eine Rückverfolgung mit

$ thread apply all bt full

(wird nach einem Segmentfehler keine core-Datei erzeugt, so versuche in einer Shell, in der du deine Anwendung startest, ulimit -c unlimited auszuführen).

gdb mit einer laufenden Anwendung verbinden

Die Fehlersuche in Anwendungen mit einem komplexen Start, z.B. Systemdienste, können sehr verzwickt sein, da du nicht alle Parameter kennst die mit der Binärdatei verwendet wurden, als dieser Dienst aufgerufen wurde.

In solch einem Fall (angenommen der Absturz tritt nicht während des Startens auf) so kannst du gdb mit einer laufenden Instanz der Anwendung verbinden.

Identifiziere zuerst den Prozess, in dem der Absturz auftritt, z.B. mit

ps ax | grep //anwendungsname//. Führt die Anwendung mehrere Prozesse aus, versuche nichts von alldem. Verursache den Absturz und überprüfe syslog um zu sehen welcher der Prozesse den Absturz verursacht, und wenn du die Anwendung wieder startest, so kannst du gdb mit dem Prozess verbinden der die relevante Stelle in der Prozessliste einnimmt.

Als nächstes verbindest du gdb mit dem verwendeten Prozess, indem du folgendes ausführst

gdb executable-name process-id

Fürst du dies aus, so wird gdb mit dem Prozess verbunden und unterbricht diesen. Um die Ausführung wieder aufzunehmen, verwende das gdb Kommando c.

Abschließend löst du den Absturz aus, der darin resultiert, dass dir gdb mehr über den Absturz mitteilt und du in einer Eingabeaufforderung landest, an der du die Rückverfolgung anfordern kannst.

Hast du gdb von einer tty aus gestartet, leite die Ausgabe in eine Textdatei um (so dass du diese später an einen Fehlerbericht anhängen kannst); dies kann durch das Kommando tee erreicht werden, so z.B.:

gdb /bin/cat 2>&1 | tee logfile.txt

dies speichert die Ausgabe in die Datei logfile.txt. Bist du fertig, so enthält die Ausgabedatei eine Aufzeichnung deiner gdb Sitzung.

Apache debuggen in Mageia 2

Apache debuggen wurde in Mageia 2 problematisch. Der unten aufgeführte Script sollte hierfür sehr nützlich sein.

#!/bin/bash

# debugging apache got broken with systemd in mga2, it used to be as easy as:
# "/etc/rc.d/init.d/httpd stop; /etc/rc.d/init.d/httpd debug"
# this script should do the trick.
# Oden Eriksson <oeriksson@mandriva.com>

/etc/rc.d/init.d/httpd stop
defines=`/etc/rc.d/init.d/httpd show_defines`
gdb /usr/sbin/httpd --batch --quiet -ex "run -f /etc/httpd/conf/httpd.conf -DNO_DETACH -DONE_PROCESS -DDEBUG $defines" -ex "thread apply all bt full" -ex "quit"

strace

Das Programm strace listet alle Systemaufrufe auf, die von der Anwendung ausgeführt wurden (öffnen einer Datei, Lesen eines Netzwerk Socket, ...) und dies kann helfen einige Fehler zu finden, wie z.B. eine vermisste Datei, ein nicht-beschreibbares Verzeichnis,... usw.

Du kannst dies wie folgt ausführen

strace -f -o \\ausgabedatei\\ \\command\\

so z.B.:

strace -f -o ls.strace ls /tmp

führt ls /tmp aus und speichert alle Systemaufrufe in der Datei ls.strac.

valgrind

Wird ein Programm unter Valgrind's supervision ausgeführt, wird jedes Lesen und Schreiben im Speicher überprüft, und Aufrufe an malloc/new/free/delete werden abgefangen. Als Resultat kann Valgrind Probleme entdecken, wir z.B.:

• Verwenden von nicht initialisiertem Speicher
• Lesen/Schreiben im Speicher nach dem dieser freigegeben wurde
• Lesen/Schreiben über das Ende des mit malloc belegten Blocks hinaus
• Lesen/Schreiben zweckwidriger Bereiche am Stapel
• Speicherlecks -- wobei Zeiger zu belegten Blöcken für immer verloren gehen
• Übergabe eines nicht initialisierten und/oder nicht-adressierbarer Speicher von Systemaufrufen
• falsch angepasste Verwendung von malloc/new/new [] vs free/delete/delete []