- Debugger
-
Ein Debugger (von engl. bug im Sinne von Programmfehler) ist ein Werkzeug zum Diagnostizieren und Auffinden von Fehlern in Computersystemen, dabei vor allem in Programmen, aber auch in der für die Ausführung benötigten Hardware.
Inhaltsverzeichnis
Namensherkunft
Der Begriff „debugging“ (dt.: entwanzen) basiert auf der von Grace Hopper eingeführten Bezeichnung für Fehler in Computersystemen. 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. Mit Bugfix (engl. fix für reparieren, ausbessern) wird die Behebung eines Programmfehlers bezeichnet.
Funktionen eines Debuggers
- die Steuerung des Programmablaufs, insbesondere durch Haltepunkte und die Einzelschritt-Verarbeitung von Befehlen
- das Inspizieren von Daten, z. B. die Register, den 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.
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.
Haltepunkte
Die wichtigste Fähigkeit eines Debuggers ist es Haltepunkte zu setzen. Diese ermöglichen es, an beliebiger Stelle des Programms, die Programmausführung zu pausieren und so die Inspizierung der Register und des Speichers zu ermöglichen.
Am häufigsten werden weiche Haltepunkte genutzt, welche ein Byte im zu untersuchenden Programm temporär verändern. Dieses Byte ist eine Instruktion, die einen Breakpoint Interrupt auslöst, welches die Programmausführung am veränderten Byte anhält.
Diese Möglichkeit hat allerdings die Beschränkung, dass das zu untersuchende Programm, sich selbst nicht auf Integrität prüfen darf (zum Beispiel durch Überprüfung einer Prüfsumme, siehe dazu auch Zyklische Redundanzprüfung). Diese Schwäche der weichen Haltepunkte nutzen Malwareprogrammierer zum Beispiel aus, um die Analyse eine Schadprogramms zu erschweren oder sogar zu verhindern.
Dieser Einschränkung unterliegen die durch Hardware realisierten Haltepunkte nicht, da diese das zu untersuchende Programm nicht verändern. Allerdings ist die Anzahl dieser Haltepunkte begrenzt, da der Prozessor nur begrenzte Ressourcen dafür besitzt.
Zur Fehlersuche verwendete Werkzeuge
Software
- DEBUG.EXE - MS-DOS Debugger
- gdb – der GNU-Debugger, ein Unix-Werkzeug
- HiTOP - Debugger/IDE von Hitex Development Tools
- iSYSTEM - – In circuit debugger für Embedded Systeme
- Lauterbach Trace 32 – In circuit debugger für Embedded Systeme
- ltrace – zeigt dynamische Bibliotheksaufrufe in Linux an
- Microsoft Visual Studio IDE Integrierter Debugger + Remote Debugger
- OllyDbg – Debugger mit GUI für Windows-Betriebssysteme
- SoftICE – Leistungsfähiger maschinennaher Debugger für x86-Systeme
- strace (Linux), truss (Solaris) – zeigt Systemaufrufe an
- The Interactive Disassembler – Disassembler für viele Rechner-Architekturen; enthält auch einen Debugger für die x86-Architektur
- TOD - ein sog. Omniscient Debugger für Java
- Turbo Debugger von Borland
- valgrind – zum Debuggen und Profilen von x86-Linux-Programmen
- Visual DuxDebugger — Debugger Disassembler for Windows 64-bit
- W32DASM – Debugger und Disassembler
Hardware
Siehe auch
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!)
Wikimedia Foundation.
