imported>CommonsDelinker: Ersetze First_Computer_Bug,_1945.jpg durch First_Computer_Bug,_1947.jpg (von CommonsDelinker angeordnet: File renamed: Criterion 3 (obvious error) · As expl

2025-12-11T04:24:09Z

Ersetze First_Computer_Bug,_1945.jpg durch First_Computer_Bug,_1947.jpg (von CommonsDelinker angeordnet: File renamed: Criterion 3 (obvious error) · As expl

Neue Seite

{{Dieser Artikel|behandelt das Programm zum Auffinden von Fehlern. Zur Tätigkeit siehe [[Debuggen]].}}
Ein '''Debugger''' (von engl. ''de-'' ([[Präfix]]; dt. ''ent-'', ''aus-'') im Sinne von ''entfernen'' und engl. ''[[Programmfehler#„Bug“ als Synonym für Programmfehler|bug]]'' im Sinne von ''Programmfehler'') ist ein [[Werkzeug]] zum Diagnostizieren und Auffinden von Fehlern in [[Computer]]systemen, dabei vor allem in [[Computerprogramm|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 ==
[[Datei:First Computer Bug, 1947.jpg|mini|hochkant=1.5|Logbuch-Seite des Mark II Aiken Relay Calculator mit dem ersten Bug (1947)]]
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 (Computer)|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.“). Daraufhin 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.<ref>{{Internetquelle |url=http://www.k12tlc.net/content/pages/byte0909.htm |titel=BYTE.com |abruf=2019-10-14}}</ref> Mit ''Bugfix'' (engl. ''fix'' für reparieren, ausbessern) wird die Behebung eines [[Programmfehler]]s bezeichnet.

== Funktionen eines Debuggers ==
[[Datei:Winpdb-1.3.6.png|mini|hochkant=1.5|Bildschirmfoto eines Debuggers]]
* die ''Steuerung'' des Programmablaufs, insbesondere durch [[Haltepunkt (Programmierung)|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 ([[Exception]]s) 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 [[Virtuelle Maschine|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 [[Anwendungsspezifische integrierte Schaltung|ASIC]], [[FPGA]] oder [[Speicherprogrammierbare Steuerung|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 [[Debugsymbol|Symbol-Informationen]] in einer speziellen Datei oder eingebettet in einem Binärprogramm (z. B. DWARF-Debug-Information) möglich. Fortgeschrittene Debugger- und [[Integrierte Entwicklungsumgebung|Entwicklungssysteme]] können weiterhin z. B. im laufenden Betrieb Daten mitschneiden, Leistungsanalysen anfertigen und [[Nebenläufigkeit|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 [[Laufzeitsystem]]en, bei der [[Parallele Programmierung|parallelen Programmierung]] oder in [[Verteilte Systeme|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 (Informatik)|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|Post-Mortem]]-Debugger in diesem Sinne eingesetzt.

== Haltepunkte ==
Die wichtigste Fähigkeit eines Debuggers besteht darin, [[Haltepunkt (Programmierung)|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 (Informationssicherheit)|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 [[Malware]]programmierer 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 [[Boolescher Operator|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 (für ''{{lang|en|Dynamic Debugging Tool}}'') – [[Digital Equipment Corporation|DEC]]/[[CP/M]]-Debugger
* [[DEBUG]] – [[MS-DOS]]-Debugger
* [[GNU Debugger|gdb]] – der [[GNU]]-Debugger, ein [[Unixoides System|Unix]]-Werkzeug
* HiTOP – Debugger/[[Integrierte Entwicklungsumgebung|IDE]] von Hitex Development Tools
* [[IBM Debug Tool]] – [[z/OS]]-Debugger mit IDE
* [[Interactive Disassembler]] (IDA) – [[Disassembler]] für viele Rechner-Architekturen; enthält u a. Debugger für die [[Arm-Architektur|Arm-]], [[MIPS-Architektur|MIPS]]-, [[m68k]]- und [[x86-Architektur|x86-]]/[[x64]]-Architektur
* iSYSTEM BlueBox mit winIDEA – In circuit debugger für [[Eingebettetes System|Embedded Systeme]]
* Lauterbach TRACE32 – In circuit debugger für Embedded Systeme
* [[ltrace]] – zeigt dynamische Bibliotheks- und Systemaufrufe in [[Linux]] an
* [[Microsoft Visual Studio]] (Entwicklungsumgebung) – integrierter Debugger + Remote Debugger
* [[OllyDbg]] – Debugger mit [[Grafische Benutzeroberfläche|grafischer Oberfläche]] (GUI) für [[Microsoft Windows|Windows]]-Betriebssysteme
* PLS Universal Debug Engine UDE - Multicore Debugger und Trace-Tool für eingebettete Systeme
* ROMWack – Bestandteil des ROMs im [[Amiga]]
* SEGGER Ozone – Debugger für Embedded Systeme
* [[Symbolic Instruction Debugger|SID]] – Debugger von [[Digital Research]], u. a. enthalten in [[CP/M]] (Ersatz für DDT) und [[DR-DOS|DR DOS]] (bis Version 6)
* [[SoftICE]] – Kernel-Modus-Debugger für [[PC-kompatibles DOS|DOS]] und Windows bis zu [[Microsoft Windows XP|Windows XP]] (1987–2000)
* [[strace]] (Linux), truss ([[Solaris (Betriebssystem)|Solaris]]), [[DTrace]] ([[macOS]]) – zeigt Systemaufrufe an
* TOD – ein sog. Omniscient Debugger für Java
* [[Turbo Debugger]] von [[Borland]]
* [[valgrind]] – zum Debuggen und Profilen von Linux-Programmen verschiedener Architekturen
* 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 ===
* [[JTAG]]
* [[Logikanalysator]]
* [[In-Circuit-Emulator]] (ICE)

== 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 (Informatiker)|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 ==
{{Wiktionary}}
* [http://www.whyprogramsfail.com/ Why Programs Fail] – Webseite zum Buch ''Why Programs Fail'' von A. Zeller, mit Programmbeispielen und Lehrmaterial (600 Folien!)

== Einzelnachweise ==
<references />

[[Kategorie:Programmierung]]

Debugger - Versionsgeschichte

imported>CommonsDelinker: Ersetze First_Computer_Bug,_1945.jpg durch First_Computer_Bug,_1947.jpg (von CommonsDelinker angeordnet: File renamed: Criterion 3 (obvious error) · As expl