51.4 jdb - Der Debugger

• 51.4 jdb - Der Debugger
  • 51.4.1 Aufruf
  • 51.4.2 Beschreibung
  • 51.4.3 Vorbereitungen

51.4.1 Aufruf

jdb [ classfile ]

51.4.2 Beschreibung

jdb ist der Debugger des JDK. Er bietet die Möglichkeit, Programme kontrolliert ablaufen zu lassen und dabei Breakpoints zu setzen, im Einzelschrittmodus den nächsten Befehl ausführen zu lassen oder den Inhalt von Variablen oder Objekten zu inspizieren. Man sollte allerdings nicht zu große Erwartungen an jdb stellen, denn das Programm ist ein Kommandozeilendebugger in schönster UNIX-Tradition. Mit den grafischen Debuggern der integrierten Java-Entwicklungsumgebungen hat er nur wenig gemeinsam. Leider ist er nicht nur umständlicher zu bedienen, sondern läßt (insbesondere in Prä-1.2-JDKs) auch einige wichtige Features moderner Debugger vermissen.

Seit der Version 1.3 besitzt das JDK eine neue Debugging-Architektur. Sie wird als JPDA (Java Platform Debugger Architecture) bezeichnet und erlaubt es, Debugger komplett in Java zu schreiben. Zwar wird nach wie vor kein ausgefeilter GUI-Debugger mit dem JDK ausgeliefert. Doch befindet sich im Unterverzeichnis jpda des Demo-Verzeichnisses des JDK ein Beispielprogramm javadt, dass als Prototyp eines GUI-Debuggers angesehen werden kann. Hinweise zu seiner Verwendung finden sich in der JDK-Dokumentation. Auch integrierte Entwicklungsumgebungen verwenden diese Schnittstelle, um ihre eigenen Debugger einzubinden.

JDK1.1-6.0

51.4.3 Vorbereitungen

Damit ein Programm debugt werden kann, sollte es mit der Option -g übersetzt werden. Dadurch werden symbolische Informationen in die Klassendatei geschrieben, die der Debugger zur Interpretation von lokalen Variablen benötigt. Beim Aufruf des Debuggers kann die zu untersuchende Klassendatei als Argument angegeben werden:

jdb classfile

Damit jdb überhaupt startet, muss ein laufender TCP/IP-Stack vorhanden sein. Dies ist für Anwender unangenehm, die nur eine Wählverbindung zu ihrem Provider haben, denn bei jedem Starten des Debuggers die Verbindung aufzubauen ist nicht nur umständlich, sondern auch kostspielig. Die übliche Empfehlung im Usenet lautet in diesem Fall, eine Datei hosts anzulegen und den folgenden Eintrag einzufügen:

Hinweis

127.0.0.1       localhost

Unter Windows 95 muss die Datei im Windows-Installationsverzeichnis (typischerweise c:\windows) angelegt werden, meist gibt es dort schon eine Kopiervorlage hosts.sam, die verwendet werden kann. In aktuellen JDKs kann auf das Anlegen der Datei unter Umständen verzichtet werden. Falls der Debugger nicht starten will, kann es sinnvoll sein, zusätzlich die DNS-Konfiguration zu deaktivieren. Dazu ist in der Systemsteuerung im Bereich »Netzwerk« das TCP/IP-Protokoll auszuwählen und nach Klick auf »Eigenschaften« im Registerblatt »DNS-Konfiguration« der Button »DNS deaktivieren« anzuklicken.

Bei dieser Anpassung ist allerdings Vorsicht geboten, denn Veränderungen an den Netzwerkeinstellungen können die Netzwerkanbindung des Rechners unbrauchbar machen. Es empfiehlt sich in jedem Fall, vor der Veränderung der Parameter die alte Konfiguration zu notieren, um sie nötigenfalls wieder restaurieren zu können. Veränderungen sollte sowieso nur derjenige vornehmen, der genau weiß, was er tut.

Warnung

Nachdem der Debugger gestartet wurde, meldet er sich mit seiner Kommandozeile und ist bereit, Befehle entgegenzunehmen. Die wichtigsten von ihnen werden in Tabelle 51.4 vorgestellt und kurz erläutert.

Kommando	Bedeutung
?	Liefert eine Übersicht aller Kommandos. Alternativ kann auch das Kommando help verwendet werden.
!!	Wiederholt das letzte Kommando.
load classname	Lädt eine Klassendatei in den Debugger. Falls jdb bereits mit einer Klassendatei als Argument aufgerufen wurde, muss dieses Kommando nicht mehr aufgerufen werden.
run	Startet das geladene Programm. Falls die Klassendatei mit load geladen wurde, müssen zusätzlich der Klassenname und ggfs. weitere Parameter des Programms übergeben werden. Nach Ausführung dieses Programms läuft das Programm bis zum nächsten Breakpoint oder bis es mit dem suspend-Kommando angehalten wird.
quit	Beendet den Debugger. Alternativ kann auch das Kommando exit verwendet werden.
stop in	Setzt einen Breakpoint auf den Anfang einer Methode. Das Kommando erwartet den Namen der Klasse, einen Punkt und den Namen der Methode als Argument. Beispiel: stop in JDBBeispiel.actionPerformed
stop at	Setzt einen Breakpoint auf eine vorgegebene Zeile. Dazu müssen der Name der Klasse, ein Doppelpunkt und die Zeilennummer innerhalb der Quelldatei angegeben werden. Beispiel: stop at JDBBeispiel:48
clear	Löscht einen Breakpoint. Als Argument müssen der Klassenname, gefolgt von einem Doppelpunkt und der Zeilennummer, in der sich der Breakpoint befindet, angegeben werden. Es gibt keine Möglichkeit, eine Liste der aktuellen Breakpoints anzeigen zu lassen.
list	Zeigt den aktuellen Ausschnitt des Quelltextes an, an dem das Programm angehalten wurde. Die als nächstes auszuführende Zeile wird durch einen Pfeil markiert. Alternativ kann auch der Name einer Methode oder eine Zeilennummer an das Kommando übergeben werden.
step	Nachdem ein Programm angehalten wurde, kann es mit diesem Kommando im Einzelschrittmodus fortgeführt werden. Befindet sich an der Aufrufstelle ein Methodenaufruf, springt das Kommando in die Methode hinein und bleibt bei der ersten ausführbaren Anweisung stehen.
next	Wie step, springt dabei aber nicht in einen Methodenaufruf hinein, sondern führt die Methode als Ganzes aus und bleibt beim nächsten Kommando nach dem Methodenaufruf stehen. Dieses Kommando steht erst ab dem JDK 1.2 zur Verfügung.
step up	Führt die aktuelle Methode bis zum Ende aus.
cont	Führt das Programm nach einem Breakpoint fort. Es läuft dann bis zum nächsten Breakpoint oder bis es mit dem suspend-Kommando angehalten wird.
print	Zeigt den Inhalt der Variablen an, die als Argument übergeben wurde. print verwendet dazu die Methode toString, die in allen Objektvariablen implementiert ist. Damit eine Variable angezeigt werden kann, muss sie an der Aufrufstelle sichtbar sein. Es gibt leider keine Möglichkeit, den Inhalt einer Variablen aus dem Debugger heraus zu verändern.
dump	Zeigt den Inhalt der Objektvariable, die als Argument übergeben wurde, inklusive aller Membervariablen an. Damit eine Variable angezeigt werden kann, muss sie an der Aufrufstelle sichtbar sein.
locals	Gibt eine Liste aller lokalen Variablen und ihrer aktuellen Inhalte aus.
where	Zeigt einen Stacktrace an.

Tabelle 51.4: Kommandos von jdb