Fehlerbereinigung

Ein Debugger (von engl. bug im Sinne von Programmfehler) ist ein Werkzeug zum Diagnostizieren, Auffinden und Beheben von Fehlern in Computersystemen, dabei vor allem in Programmen, aber auch in der für die Ausführung benötigten Hardware.

Funktionen eines Debuggers

• die Steuerung des Programmablaufs, insbesondere durch Haltepunkte und die Einzelschritt-Verarbeitung von Befehlen
• das Inspizieren von Daten, z. B. die Register, dem aktuellen Programmcode als Assembler oder Hochsprachenquelltext, den allgemeinen Daten in festen und flüchtigen Speichern, der Erzeugung von fortgeschrittenen Daten-Interpretationen etwa durch eine Callstack-Funktionalität oder das Anzeigen von Ein-/Ausgabe-Registern, Tabellen und Hochsprachen-Strukturen
• das Modifizieren von Speichern, z. B. des Hauptspeichers, der externen Ein-/Ausgabe-Zustände und der Register des Prozessorkerns

Je nach Debugger und Beschaffenheit der Hardware ist es auch möglich, Rückmeldungen und Fehlerzustände (Exceptions) des Zielsystems aufzufangen. Hier sind vor allem Speicherzugriffsfehler interessant, ungültige Opcodes und Befehlsfolgen, bei denen Eingangs- oder Ausgangsgrößen fraglich sind, etwa eine versuchte Division durch Null.

Man unterscheidet grundsätzlich zwischen Remote-Debugging von entfernten Systemen und Debugging, das innerhalb des zu untersuchenden Prozessorsystems mit Bord-Mitteln vorgenommen wird. Eine Spezialversion ist das Remote-Debugging mittels einer Simulation des Zielsystems durch eine Prozessor-Simulation und weitere Elemente. Das Debuggen einer virtuellen Maschine stellt eine Zwischenform zwischen den beiden Typen dar, wobei die virtuelle Maschine prinzipiell sowohl den Charakter einer lokalen Anwendung wie auch eines eigenständigen Systems hat. Die Überwindung der Prozessor-Architektur stellt zumindest grundsätzlich einen gewissen Aufwand dar. Je nach Art der Konzeption sind beim Debugging sogar taktgenaue Bestimmungen des Laufzeitverhaltens möglich wobei z.B. eine Simulation hierbei nicht zwangsweise in Echtzeit ablaufen muss. Bei Simulationen von Halbleitern der Kategorie ASIC, FPGA oder PLC sind sowohl Hardware- wie auch Software-Simulationen gängige Hilfsmittel, die über einen entsprechend speziellen Debugger für den Entwickler zugänglich sind.

Einfache Fehlersuche auf Assembler-Ebene ist bei einem dafür ausgelegten System jederzeit möglich. Manche Hochsprachen, wie etwa Skripte oder diverse BASIC-Varianten, lassen sich dagegen oft nur zeilenbasiert auf Quelltextebene untersuchen. Erweiterte Funktionalitäten, z. B. das Auflösen von Symbolen, Strukturen und Funktionsnamen werden mit dem Vorhandensein von Symbol-Informationen in einer speziellen Datei oder eingebettet in einem Binärprogramm (z. B. DWARF-Debug-Information) möglich. Fortgeschrittene Debugger- und Entwicklungssysteme können weiterhin z. B. im laufenden Betrieb Daten mitschneiden, Leistungsanalysen anfertigen und nebenläufige Vorgänge visualisieren.

Ein Debugger ist systematisch am ehesten vergleichbar mit dem, was in der Elektrotechnik und Elektronik durch die typischen Messgeräte und Hilfsmittel, z. B. einen Logik-Tester, ein Multimeter, ein Oszilloskop oder einen Signalgenerator, an Möglichkeiten für die Inbetriebnahme und Überwachung von entsprechenden Systemen zur Verfügung steht.

Moderne Debugger haben die Möglichkeit, Änderungen am Quelltext während der Programmausführung direkt zu übersetzen und anschließend das Programm fortzusetzen. Diese Technik wird auch als just in time debugging bezeichnet. Ein Debugger ist oft Bestandteil einer Programm-Entwicklungsumgebung.

Bei der Fehlerkorrektur und -lokalisierung mit einem Debugger spricht man auch von Debuggen. Der Wortbestandteil Bug für „Programmierfehler“ wurde von der Computerpionierin Grace Hopper geprägt. Mit Bugfix (engl. fix für reparieren, ausbessern) wird die Behebung eines Programmfehlers bezeichnet.

Darüber hinaus kann ein Debugger beim Reverse Engineering auch dazu eingesetzt werden, um mit der Ablaufverfolgung und dem Untersuchen von Variablen Fremdprogramme besser und schneller zu verstehen.

In objektorientierten Laufzeitsystemen, bei der parallelen Programmierung oder in verteilten Systemen ist es sehr schwierig oder in der Praxis sogar unmöglich, eine genaue Programmabfolge zu definieren. Einige Entwicklungssysteme verzichten daher auf den Einsatz von Laufzeit-Debuggern, lassen aber in der Regel die Definition von Haltepunkten zu, an dem der Zustand aller Variablen nach dem Programmstopp analysiert werden kann. Auch bei der Ausnahmebehandlung, also nach Programmunterbrechungen, die zum Beispiel durch einen Fehler erzwungen werden, werden so genannte Post-Mortem-Debugger in diesem Sinne eingesetzt.

Zur Fehlersuche verwendete Werkzeuge

• Software:
  • gdb – der GNU-Debugger, ein Unix-Werkzeug
  • ddd – eine grafische Oberfläche zum gdb
  • cgdb – ein auf curses basierendes Frontend zu gdb
  • ltrace – zeigt dynamische Bibliotheksaufrufe in Linux an
  • strace (Linux), truss (Solaris) – zeigt Systemaufrufe an
  • valgrind – zum Debuggen und Profilen von x86-Linux-Programmen
  • SoftICE – Leistungsfähiger maschinennaher Debugger für x86-Systeme
  • IDA – Disassembler für viele Rechner-Architekturen; enthält auch einen Debugger für die x86-Architektur.
  • OllyDbg – Debugger mit GUI.
  • W32DASM – Debugger und Disassembler.
  • Microsoft Visual Studio IDE Integrierter Debugger + Remote Debugger
  • debug.exe - MS-DOS Debugger
  • Turbo Debugger von Borland
  • Lauterbach Trace 32 – In circuit debugger für Embedded Systeme
  • iSYSTEM - – In circuit debugger für Embedded Systeme

• Hardware:
  • JTAG
  • Logic-Analyzer
  • ICE – In-Circuit-Emulator

Namensherkunft

Häufig wird auch der Begriff „debugging“ (dt.: entwanzen) auf Grace Hopper zurückgeführt. 1947 hatte während der Arbeiten an Mark II eine Motte für den Ausfall eines Relais dieses Computers gesorgt. Grace Hopper hat die (tote) Motte in das Logbuch geklebt und mit dem Satz „First actual case of bug being found.“ („Das erste Mal, dass tatsächlich ein Bug gefunden wurde.“) kommentiert. Der Begriff „Bug“ war im Englischen unter Ingenieuren bereits seit längerer Zeit als Bezeichnung für Fehlfunktionen in Gebrauch.

Siehe auch

• Softwaretest
• Delta Debugging
• Disassembler

Literatur

• David J. Agans: Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems, AMACOM, 2002. ISBN 0-8144-7168-4
• Ann R. Ford, Toby J. Teorey: Practical Debugging in C++, Prentice Hall, 2002. ISBN 0-13-065394-2
• Matthew A. Telles, Yuan Hsieh, Matt Telles: The Science of Debugging, The Coriolis Group, 2001. ISBN 1-57610-917-8
• Andreas Zeller: Why Programs Fail: A Guide to Systematic Debugging, Dpunkt Verlag, 2005. ISBN 3-89864-279-8

Weblinks

• Why Programs Fail – Webseite zum Buch Why Programs Fail von A. Zeller, mit Programmbeispielen und Lehrmaterial (600 Folien!)