Debugger
Ein Debugger (von engl. de- (Präfix; dt. ent-, aus-) im Sinne von entfernen und 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. Debugging bezeichnet die Tätigkeit, solche Fehler zu diagnostizieren und aufzufinden, sei es unter Verwendung eines Debuggers oder anderer Methoden.
Namensherkunft
Der Begriff „debugging“ (zu deutsch entwanzen) wird häufig Grace Hopper zugeschrieben, eine Legende, die sie selber gerne erzählte, welche allerdings nicht ganz korrekt ist. 1947 hatte während der Arbeiten am Mark II eine Motte für den Ausfall eines Relais dieses Computers gesorgt. Das Team von Grace Hopper fand die Motte und klebte sie in das Logbuch zusammen mit dem Satz „First actual case of bug being found.“ („Das erste Mal, dass tatsächlich ein Bug gefunden wurde.“). Darauf hin soll sich die Bezeichnung „debugging“ für „Fehlersuche“ im Team eingebürgert haben. Der Begriff „Bug“ (für Insekt, Käfer, Schädling) war allerdings im Englischen unter Ingenieuren bereits seit dem 19. Jahrhundert als Bezeichnung für Fehlfunktionen in Gebrauch und wurde entsprechend bereits 1937 im Webster's New International Dictionary als Slang erwähnt.[1] 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 Aufrufstapel-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 Konzeption sind beim Debugging sogar taktgenaue Bestimmungen des Laufzeitverhaltens möglich, wobei z. B. eine Simulation dabei 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 sogenannte Post-Mortem-Debugger in diesem Sinne eingesetzt.
Haltepunkte
Die wichtigste Fähigkeit eines Debuggers besteht darin, Haltepunkte zu setzen. Diese ermöglichen es, an beliebiger Stelle eines Programms dessen Ausführung zu unterbrechen und so die Untersuchung der Register und des Speichers zu ermöglichen.
Am häufigsten werden Software-Haltepunkte genutzt, welche ein Byte im zu untersuchenden Programm temporär verändern. Dieses Byte ist die Anweisung, einen Breakpoint Interrupt auszulösen, die Programmausführung beim veränderten Byte anzuhalten.
Diese Möglichkeit beinhaltet allerdings die Einschrä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 eines Schadprogramms zu erschweren oder sogar zu verhindern.
Dieser Einschränkung unterliegen die Hardware-Haltepunkte nicht, da diese das zu untersuchende Programm nicht verändern. Hardware-Haltepunkte sind direkt im Prozessor realisiert; allerdings besitzt dieser nur begrenzte Ressourcen dafür, so dass nur eine begrenzte Anzahl dieser Haltepunkte zur Verfügung steht.
Viele Debugger erlauben es dem Programmierer, bedingte Haltepunkte zu setzen. Dabei gibt der Programmierer neben der Anweisung, wo die Programmausführung angehalten werden soll, den Befehl für einen booleschen Ausdruck an. Der Debugger unterbricht die Programmausführung nur dann, wenn die angegebene Codezeile erreicht wurde und gleichzeitig der boolesche Ausdruck wahr ist.
Damit der Debugger testen kann, ob der boolesche Ausdruck wahr ist, muss dieser allerdings die Programmausführung temporär unterbrechen und den booleschen Ausdruck überprüfen, worauf der Debugger dann entweder die Programmausführung fortsetzt oder das Programm im unterbrochenen Zustand lässt.
Zur Fehlersuche verwendete Werkzeuge
Software
- Compuware Xpediter – z/OS Debugger
- DDT – DEC / CP/M Debugger
- DEBUG.EXE – MS-DOS Debugger
- gdb – der GNU-Debugger, ein Unix-Werkzeug
- HiTOP – Debugger/IDE von Hitex Development Tools
- IBM Debug Tool – z/OS Debugger und IDE
- iSYSTEM BlueBox mit winIDEA – In circuit debugger für Embedded Systeme
- Lauterbach TRACE32 – In circuit debugger für Embedded Systeme
- SEGGER Ozone - Debugger für Embedded Systeme
- ltrace – zeigt dynamische Bibliotheks- und Systemaufrufe in Linux an
- Microsoft Visual Studio IDE Integrierter Debugger + Remote Debugger
- OllyDbg – Debugger mit GUI für Windows-Betriebssysteme
- ROMWack – Bestandteil des ROMs im Amiga
- SoftICE – Kernel-Modus-Debugger für DOS und Microsoft Windows bis zu Windows XP (1987 - 2000 (Letzte Veröffentlichung))
- strace (Linux), truss (Solaris), DTrace (macOS) – 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 für Windows 64-bit
- WinDbg, KD/CDB, NTSD — Windows-Debugger für x86-, Itanium, und x64-Systeme, Bestandteil der Debugging Tools for Windows
- W32DASM – Debugger und Disassembler
- x64dbg - Debugger mit GUI für Windows-Betriebssysteme
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.
- Thorsten Grötker, Ulrich Holtmann, Holger Keding, Markus Wloka: The Developer's Guide to Debugging, 2. Ausgabe, CreateSpace Independent Publ., 2012, ISBN 978-1-4701-8552-7.
- John Robbis: Microsoft .NET 2.0 Anwendungen debuggen, Praktische (...) mit Visual Studio 2005, deutsch, MicrosoftPress Deutschland, 2007, ISBN 978-3-86645-408-8
Weblinks
- Why Programs Fail – Webseite zum Buch Why Programs Fail von A. Zeller, mit Programmbeispielen und Lehrmaterial (600 Folien!)
Einzelnachweise
- BYTE.com. Abgerufen am 14. Oktober 2019.