SuSE GmbH

SuSE Support-Datenbank

Titel: Debuggen mit der Glibc

----------

Übersicht o Stichwortsuche o History o Versionen o Kategorien o Alle Artikel
English

----------

Debuggen mit der Glibc

Bezieht sich auf

glibc: Version 2.1

Debuggen mit Unterstützung der Glibc

Dieser Artikel zeigt einige Features der GNU C library (glibc 2.1) Version 2.1 (oder neuer), die beim Debuggen von Anwendungen und Libraries hilfreich sein können. Diese Features führen zu zusätzlichen Debugmöglichkeiten, die bei Benutzung eines normalen Debuggers, wie gdb, oder Trace-Programmen, wie strace und ltrace nicht zur Verfügung stehen.

Glibc hat ein eigenes (englischsprachiges) Manual, daß die meisten Sachen bereits dokumentiert. Anstelle einer Duplikation der Information, werde ich Hinweise auf das Manual geben. Einige Bereiche der glibc sind noch nicht so gut dokumentiert, hier ist dieses Dokument bisher die einzige Dokumentation.

Hilfreiche Eigenschaften der glibc zum Debuggen:

Debuggen von Malloc-Problemen

Die Malloc-Implementierung ist weniger robust in Bezug auf fehlerhafte Aufrufe, als einige andere Malloc-Implementierungen - hat aber dafür andere Eigenschaften, wie geringer Speicherplatzbedarf, Thread-Sicherheit und Schnelligkeit. Falls beispielsweise ein Pointer mehr als einmal mit der Funktion free freigegeben wird, oder der allozierte Speicher um ein Byte überschrieben wird, kann es zu Segmentation Faults kommen. Dieses Eigenschaft hilft aber auch Bugs zu finden.

Zur Verdeutlichung will ich betonen, daß ein Segmentation Fault in einer der Malloc-Funktionen, wie z.B. __free oder chunk_alloc ist immer auf einen Fehler in der Benutzung der Routinen zurückzuführen. Sich über einen Fehler in den Mallocroutinen zu beschweren bringt nichts - es ist (bisher jedenfalls;-) immer auf einen Bug in dem Anwendungsprogramm zurückzuführen.

Glibc besitzt aber auch eine Reihe von Tools um Malloc Probleme zu debuggen. Der Einsatz einiger dieser Tools setzt aber ein Neuübersetzen des fehlerhaften Programmes voraus.

Konsistenz-Checks

Eine Art Fehler in der Benutzung von malloc, realloc und free zu finden, wird durch das Setzen der Environment Variable MALLOC_CHECK_ (der Unterstrich am Ende ist wichtig und sollte nicht vergessen werden) eingestellt. Falls MALLOC_CHECK_ gesetzt ist, so wird eine spezielle, aber weniger effiziente, Implementierung benutzt, die gegen simple Fehler tolerant ist, wie mehrfache Aufrufe von free mit dem gleichen Argument, oder Überläufe von einem Byte (Off-by-One Fehler). Es kann aber nicht gegen alle Fehler gesichert werden und Memoryleaks können auftreten.

Falls MALLOC_CHECK_ 0 ist, wird jede Verletzung der internen Datenstrukturen stillschweigend ignoriert; falls die Variable auf 1 gesetzt ist, so wird eine Meldung auf stderr geschrieben; im Fall, daß es 2 ist, wird abort direkt aufgerufen. Dies ist oft nützlich, da ansonsten ein Crash viel später auftreten kann und der wahre Grund für den Absturz schwierig zu finden ist.

Eine andere Möglichkeit ist das Eincompilieren von speziellen Memorychecks in das Programm. Für Details sei auf das Glibc Manual verwiesen, das z.B. mittel info libc "Heap Consistency Checking") angezeigt werden kann.

Suchen nach Memory Leaks

Das Finden von Memory Leaks, also Allozierung von Speicher, der nie freigegeben wird, ist manuell nicht einfach, da jeder (auch indirekte) malloc und free Aufruf geprüft werden muß. Die Glibc kommt mit einem Tool zum automatischen Suchen nach Memory Leaks, es heißt mtrace. Eine ausführliche Beschreibung findet sich im Glibc Manual. Der entsprechenden Abschnitt läßt sich beispielsweise durch Eingabe von info libc "Allocation Debugging" lesen.

Erzeugen eines Stacktraces

Falls ein Programm mit einen Segmentation Fault beendet wird, kann ein Stacktrace mit dem Befehl catchsegv erzeugt werden. Es reicht das Programm, das den Segmentation Fault produziert, als Argument zu übergeben, also z.B. catchsegv buggy.

Um einen Stacktrac in einem eigenen Program zu erzeugen, kann die Funktion backtrace aus <execinfo.h> benutzt werden. In der Header-Datei sind noch einige Varianten von backtrace definiert.

Probleme mit dynamisch gelinkten Bibliotheken

Zum Debuggen des dynamischen Bindens von Programmen, kann der dynamische Linker verschiedene Arten von Debug-Meldungen ausgeben. Die Ausgaben werden über die Environment-Variable LD_DEBUG gesteuert. Wird dies auf help, so wird eine Liste von möglichen Optionen ausgeben. Beispielsweise ist die Ausgabe von LD_DEBUG=help ls:
Valid options for the LD_DEBUG environment variable are:

  bindings  display information about symbol binding
  files     display processing of files and libraries
  help      display this help message and exit
  libs      display library search paths
  reloc     display relocation processing
  symbols   display symbol table processing
  versions  display version dependencies

To direct the debugging output into a file instead of standard output
a filename can be specified using the LD_DEBUG_OUTPUT environment variable.
Falls mehr als eine Option gebraucht wird, so müssen diese durch Kommas getrennt werden, also z.B. LD_DEBUG=files,libs program.

Das Programm ldd gibt eine Liste aller Libraries aus, die ein Program oder eine Library zur Laufzeit benötigen.

----------

Stichwörter: DEBUGGEN, MALLOC, GLIBC

----------

Kategorien: Entwicklungswerkzeuge

----------

Feedback willkommen: Send Mail to aj@suse.de (Geben Sie bitte folgendes Stichwort an: SDB-aj_debug)

----------

Übersicht o Stichwortsuche o History o Versionen o Kategorien o Alle Artikel
English

----------

SDB-aj_debug, Copyright SuSE GmbH, Nuremberg, Germany
SuSE GmbH - Zuletzt generiert: 25. Nov 1999 16:06:00 by aj with sdb_gen 1.00.0