The Java Debugger. Seminararbeit von Felix Frei. Fachhochschule Aargau Departement Technik Studiengang I

Transkript

1 The Java Debugger Seminararbeit von Felix Frei Fachhochschule Aargau Departement Technik Studiengang I Betreuender Dozent: Prof. Dr. Dominik Gruntz Windisch, 16. Mai 2002

2 Abstract JPDA is a multi-tiered debugging architecture that allows tools developers to easily create debugger applications which run portably across platforms, virtual machine (VM) implementations and SDK versions. It provides a way both to inspect the state and to control the execution of applications running in the Java TM Virtual Machine. The Java Platform Debugger Architecture (JPDA) consists of two interfaces (JVMDI and JDI), a protocol (JDWP) and two software components which tie them together (back-end and front-end). The Java Debugger, jdb, is a simple command-line debugger for Java classes. It is a demonstration of the Java Platform Debugger Architecture that provides inspection and debugging of a local or remote Java Virtual Machine.

3 Zusammenfassung JPDA ist eine Debugging Architektur, die es Entwicklern erlaubt eine portable Debug-Applikation zu schreiben. Einerseits wird die Möglichkeit zur Verfügung gestellt, den Status einer Applikation, die in einer Virtullen Maschine läuft zu überprüfen und andererseits auch die Ausführung dieser zu steuern. Die Java Platform Debugger Architektur (JPDA) besteht aus zwei Interfaces (JVMDI and JDI), einem Protokoll (JDWP) und zwei Software Komponenten, welche sie zusammen fügt (back-end und front-end). Der Java Debugger, jdb, ist ein einfacher Kommandozeilen Debugger für Java Klassen. Er ist eine Demonstration der Java TM Platform Debugger Architektur und bietet die Möglichkeit lokale und remote Java Virtual Maschinen zu debuggen.

4 Inhaltsverzeichnis Einleitung 1 1 Java TM Plattform Debugger Architektur Komponenten HotSwap Class File Replacement Beispiel JDI Applikationen von Sun JSwat Debugger Interfaces Java TM Virtual Machine Debug Interface (JVMDI) Java TM Debug Wire Protocol (JDWP) Java TM Debug Interface (JDI) Verbindung und Aufruf Transport Connectors jdb - The Java TM Debugger Verwendung mit einer neuen Java TM Virtual Machine Hinzufügen zu einer bestehenden Java TM Virtual Machine jdb-kommandos Kommando Zeilen Optionen Testversuche mit jdb Schlusswort 16 A Beispiel debugging eines Servlet 17

5 INHALTSVERZEICHNIS ii Literaturverzeichnis 20

6 Einleitung Im Rahmen der verschieden Seminarberichte war ein Thema der Java Debugger jdb. Über das Debuggen von Applikation hört man sehr unterschiedliche Meinungen. Während die einen Entwickler auf Fehlersuche mit einem Debugger schwören, sehen andere in diesen Tools keinen grossen Vorteil. Sie sind der Meinung, dass man mit Hilfe eines sauberen Programmierstils und Konsolenausgabe Fehler genauso gut finden kann, was sicherlich unbestritten ist. Trotz allem bin ich der Meinung, dass ein geschickt eingesetzter Debugger zum Lösen von Problemen beitragen kann. Dieser Bericht soll auf der einen Seite dem interessierten Leser die Möglichkeiten geben die Java TM Plattform Debugger Architektur kennen zu lernen. Auf der anderen Seite werden verschiedene Einsatzmöglichkeiten des Tools jdb erläutert. Die Seminararbeit richtet sich vor allem an Java TM Entwickler, die die entsprechenden Vorkenntnisse besitzen. Da die ganze Architektur sehr umfangreich ist, wäre es eine Illusion zu glauben, dass man nach dem Lesen dieser Arbeit das nötige Wissen hat, um einen Debugger zu implementieren. Viel mehr dient diese Arbeit als Sprungbrett für Entwickler, die sich in diese Materie einarbeiten wollen, oder einfach sehen möchten, welche Möglichkeiten das Tool jdb zu bieten hat.

7 Kapitel 1 Java TM Plattform Debugger Architektur JPDA ist eine Debugging Architektur die es Entwicklern erlaubt eine portable Debug-Applikation zu schreiben. JPDA existiert in dieser Form seit der Standard Edition (J2SETM) SDK 1.3 auf allen Plattformen und seit SDK für Linux. Sie besteht aus folgenden Komponenten. [2] Abbildung 1.1: JPDA-Komponenten

8 1.1. KOMPONENTEN Komponenten debuggee Debuggee ist der Prozess, der zu debuggen ist. Er enthält die Anwendung, die gedebuggt wird, die Target-VM (Virtual Machine), unter der die Anwendung läuft und das back-end des Debuggers. Java TM Virtual Machine (VM) VM ist die Target-Virtual-Machine, auf der die zu debuggende Anwendung läuft. Die Debugger-Architektur ist für ein weites Spektrum an VM- Implementierungen ausgelegt. Die VM implementiert das Java TM Virtual Machine Debug Interface (JVMDI). back-end Das back-end ist für die Kommunikation zwischen dem Debugger-front-end und der Target-VM vorgesehen. Die Kommunikation läuft über einen communication channel, der das Java TM Debug Wire Protocol (JDWP) benutzt. Das backend benutzt für die Kommunikation mit der VM das Java TM Virtual Machine Debug Interface (JVMDI). communication channel Der communication channel ist die Verbindung zwischen dem front-end und dem back-end des Debuggers. Der Transportmechanismus ist unspezifisch. Als mögliche Mechanismen kommen in Frage: Sockets Serielle Leitungen Shared Memory Das Format und die Semantik des serialized bit-stream Flusses über den Channel, werden durch das Java TM Debug Wire Protocol (JDWP) festgelegt. front-end Das Debugger front-end implementiert das high-level Java TM Debug Interface (JDI). Das front-end nutzt die Information vom low-level Java TM Debug Wire Protocol (JDWP).

9 1.2. HOTSWAP CLASS FILE REPLACEMENT 4 User Interface (UI) Das User Interface (UI) des Debuggers ist nicht spezifiziert. Hier hat der Anwender die Möglichkeit, seine eigenen Debug-Tools einzuhängen. Als Beispiels- Implementierungen enthält das JPDA-Paket die Programme JDB und JA- VADT. Diese Anwendungen benutzen das Java TM Debug Interface (JDI). 1.2 HotSwap Class File Replacement Seit jdk1.4 hat man neu die Möglichkeit Code während einer Debugg-Session zu ändern und neu zu kompilieren. Der Code wird also zur Laufzeit ausgetauscht und man muss die Applikation nicht nach jeder Korrektur neu starten. Dies kann von Vorteil sein, wenn man ein Server hat den man reparieren muss, diesen aber nicht jedes Mal herunterfahren kann. Natürlich sind dem HotSwap Class File Replacement Grenzen gesetzt. So werden Objekte die bereits auf dem Stack sind natürlich nicht erneuert, ausser diese werden neu instanziert. 1.3 Beispiel JDI Applikationen von Sun Sun stellt 3 Beispielprogramme zur Verfügung die den Einstieg erleichtern sollen falls man ein Debugger programmieren möchte. Trace Zeigt die Spuren der Programmausführung auf. Jdb Der Kommandozeilen Debugger von Sun, der mit dem J2SE SDK ebenfalls mitgeliefert wird. Javadt Ein sehr simpler GUI Debugger. Man findet den Sourcecode mit Dokumentation in folgendem File. C:\j2sdk1.4.0\demo\jpda\examples.jar 1.4 JSwat JSwat ist ein erweiterbares graphisches standalone Java Debugger Frond-End. Dieses verwendet die Java Platform Debugger Architecture (JPDA). Das Programm unterliegt der GNU General Public License und es sind sowohl der Source Code wie auch die Binarys erhältlich. Dieser Debugger ist sehr ausgereift und unterstützt ziemlich viele Möglichkeiten, die sich einem mit der JPDA bieten.[8]

10 Kapitel 2 Debugger Interfaces 2.1 Java TM Virtual Machine Debug Interface (JVM- DI) Das Java TM Virtual Machine Debug Interface (JVMDI) ist ein Programmier Interface, das von Debugger und anderen Programmiertools verwendet werden kann. Es stellt einerseits die Möglichkeit zur Verfügung, den Status einer Applikation, die in der Virtuellen Maschiene läuft, zu überprüfen. Andererseits auch die Ausführung dieser zu steuern. JVMDI Klienten laufen in der selben Virtuellen Maschine wie die Applikation, die zu debuggen ist. Der Zugriff zum JVMDI geschieht via native Interface.[3] 2.2 Java TM Debug Wire Protocol (JDWP) Das Java TM Debug Wire Protokoll ist das Protokoll, welches für die Kommunikation zwischen Debugger und der virtuellen Maschine verwendet wird in der die Applikation läuft, die man debuggen möchte. Dank dem Java TM Debug Wire Protokoll ist es möglich einerseits auf dem selben Computer über verschiedene Prozesse hinweg zu arbeiten, und andererseits auch eine Verbindung mit einem remote Computer aufzunehmen. Der Unterschied des JDWP zu vielen anderen Protokollspezifikationen liegt darin, dass zwar das Format und das Layout spezifiziert sind, nicht aber der Transportmechanismus. Je nach JDWP Implementation sind verschiedene Transportmechanismen möglich.[4] JDWP Pakete Man unterscheidet grundsätzlich die zwei Pakettypen command und replay. Command Pakete werden entweder vom Debugger oder der Ziel virtuellen Maschine versendet. Sie werden vom Debugger verwendet um Information von einer virtuellen Maschine anzufordern oder um die Ausführung einer Applika-

11 2.3. JAVA TM DEBUG INTERFACE (JDI) 6 tion zu kontrollieren. Die VM sendet command Pakete, um dem Debugger Events, wie Breakpoints oder Exceptions, mitzuteilen. Ein replay Paket wird nur als Antwort auf ein command Paket versendet und enthält Information über Erfolg oder Fehler des command Paketes. Replay Pakete können auch Daten enthalten, die vom command Paket angefordert wurden. Zum Beispiel den Wert einer Variable. 2.3 Java TM Debug Interface (JDI) Das Java TM Debug Interface (JDI) ist eine High Level Java TM API, die Information für Debugger oder ähnliche Systeme zur Verfügung stellt, die Zugriff zu einer laufenden Java TM Virtual Maschine benötigen. Das JDI Interface stellt introspektiven Zugriff zu folgenden Komponenten einer Java TM Virtual Maschine sicher. Insbesondere kann man auch private Merkmale inspizieren. Status Klassen Interfaces Primitive Typen Instanzen von primitiven Typen Das JDI Interface stellt auch explizite Kontrolle bei der Ausführung der Virtuellen Maschine zur Verfügung. Man hat die Möglichkeit Threads zu suspendieren und wiederaufzunehmen, Breakpoints zu setzen und ein entsprechend suspendierten Thread zu untersuchen. JDI ist der höchste Layer der Java TM Platform Debugger Architektur (JPDA).[5]

12 Kapitel 3 Verbindung und Aufruf 3.1 Transport Ein JPDA Transport ist eine Kommunikation zwischen zwei Prozessen und zwar auf der einen Seite die Debugger Applikation und auf der anderen Seite die Virtuelle Maschine, die zu debuggen ist. Diese Transport Implementation erlaubt die Kommunikation sowohl zwischen Prozessen auf der selben Maschinen, wie auch zwischen Prozessen auf verschiedenen Maschinen. Wenn zwischen einer debugger Applikation und einer Ziel-VM eine Verbindung aufgebaut wird, so übernimmt die eine Seite die Rolle des Servers und wartet auf die Verbindung, während die andere Seite dann später mit dem Server eine Verbindung aufnehmen kann. JPDA-Kommunikation erlaubt sowohl der Debugger Applikation wie auch der Ziel VM als Server zu agiren. Die JPDA Referenz Implementation auf der Win 32 Plattform erlaubt sowohl den Transport über Sockets, wie auch über shared memory. Die Referenz Implementation auf Solaris hingegen unterstützt nur den Socket Transport.[6] Socket Transport Der Socket Transport verwendet Standard TCP/IP Sockets, um zwischen der Debugger Applikation und der Ziel VM zu kommunizieren. Falls die Kommunikation über Sockets geschieht, müssen die Debugger Applikation und die Ziel-VM nicht zwingend auf der selben Maschine sein. Shared Memory Transport Nebst dem Transport über Socket, hat man auf der Win32 Plattform auch die Möglichkeit eine Verbindung über shared memory aufzubauen. Unter Verwendung des shared memory Transport müssen aber die Debugger Applikation und die Ziel VM auf der selben Maschine sein.

13 3.2. CONNECTORS Connectors Ein Connector ist eine JDI Abstraktion die verwendet wird, um eine Verbindung zwischen einer Debugger Applikation und einer Ziel VM aufzubauen. Verschiedene JDI Implementationen unterstützen diverse Connectoren für eine Verbindung. Hier werden die Connectoren kurz erläutert und jeweils ein Beispiel angegeben. Je nach Beispiel muss nicht nur der Debugger entsprechend gestartet werden, sondern auch die Applikation, die zu debuggen ist. Je nach Connector muss zuerst der Debugger oder zuerst die Applikation gestartet werden. Die Applikation die zu debuggen ist, muss entsprechend gestartet werden, wobei man normalerweise die Option -Xrunjdwp verwendet: Sun Command Line Launching Connector Dieser Connector kann verwendet werden, um eine Sun VM oder eine beliebige VM zu starten, welche die selben Aufruf-Optionen unterstützt. Unter Windows geschieht der Transport via Shared Memory, während auf der Solaris der Socket Transport verwendet wird. F:\jdb\TestProg>jdb -connect com.sun.jdi.commandlinelaunch:main=myclass Raw Command Line Launching Connector Um eine beliebige VM zu starten, hat man einen weiteren Connector zur Verfügung. Unter Windows geschieht der Transport via Shared Memory, während auf der Solaris der Socket Transport verwendet wird. F:\jdb\TestProg>jdb -connect com.sun.jdi.rawcommandlinelaunch:command="java MyClass" Socket Attaching Connector Um via Socket eine Verbindung zu einer bereits laufenden Virtuellen Maschine aufzubauen, existiert ein Socket Attaching Connector, wobei aber die Ziel Virtuelle Maschine mit entsprechenden Optionen gestartet werden muss. SHELL 1 F:\jdb\TestProg>java -Xdebug -Xrunjdwp:transport=dt_socket,server=y MyClass Listening for transport dt_socket at address: 3011 SHELL2

14 3.2. CONNECTORS 9 jdb -connect com.sun.jdi.socketattach:port=3011,hostname=localhost Shared Memory Attaching Connector Wie bereits erwähnt, hat man auf der Windows Plattform die Möglichkeit via Shared Memory eine Verbindung zu einer bereits laufenden Virtuellen Maschine aufzubauen. Die Virtuelle Maschine muss ebenfalls mit entsprechenden Optionen gestartet werden. SHELL 1 F:\jdb\TestProg>java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=jdbconn MyClass SHELL 2 jdb -connect com.sun.jdi.sharedmemoryattach:name=jdbconn Shared Memory Listening Connector Ein Debugger kann auch via Shared Memory ein Aufruf von einer separaten Virtuellen Maschine akzeptieren. Bei dieser Art von Verbindung, agiert der Debugger als Server und wird zuerst gestartet. SHELL 1 jdb -connect com.sun.jdi.sharedmemorylisten:name=jdbconn Listening at address: jdbconn SHELL 2 F:\jdb\TestProg>java -Xdebug -Xrunjdwp:transport=dt_shmem,server=n,address=jdbconn MyClass Socket Listening Connector Eigentlich besteht auch die Möglichkeit eine Debugger Applikation zu starten und dann von einer anderen Virtuellen Maschine aus eine Verbindung via Sockets zu erstellen. Leider funktioniert dieser Connector aber nicht richtig, es handelt sich vermutlich um einen Bug in der Virtuellen Maschine! SHELL 1 ia99frei@mr6550b:~> jdb -connect com.sun.jdi.socketlisten:port=33333

15 3.2. CONNECTORS 10 Listening at address: mr6550b.fh-aargau:33333 SHELL 2 ia99frei@mr6550b:/windows/e/jdb/testprog> java -Xrunjdwp:transport=dt_socket, server=n,address=localhost:33333 MyClass.. Local Time = Sat May 4 17:13: Elapsed Time = 0 # # HotSpot Virtual Machine Error : 11 # Error ID : 4F530E CC # Please report this error at # # # Java VM: Java HotSpot(TM) Client VM (1.3.1-b24 mixed mode) # # An error report file has been saved as hs_err_pid5358.log. # Please refer to the file for further information. # Aborted ia99frei@mr6550b:/windows/e/jdb/testprog>

16 Kapitel 4 jdb - The Java TM Debugger Der Java TM Debugger jdb ist ein simples Kommandozeilentool (Wie der Interpreter, Compiler und der Appletviewer). Man kann den jdb auch als Demonstration der Java TM Platform Debugger Architecture betrachten. Diese unterstützt das Debuggen von lokalen und remote Java TM Virtual Maschinen. Die Klassen die man debuggen möchte, müssen mit der Option -g kompiliert werden, falls man auch auf lokale Variablen zugreifen möchte.[7] 4.1 Verwendung mit einer neuen Java TM Virtual Machine Am einfachsten ist der jdb einfach so zu verwenden, als würde man eine Klasse mit dem Interpreter ausführen. jdb classname <arguments> 4.2 Hinzufügen zu einer bestehenden Java TM Virtual Machine Die zweite Methode mit dem jdb zu debuggen, ist eine Verbindung zu einer laufenden Virtuellen Maschine aufzubauen. Hier stehen zahlreiche Möglichkeiten zur Verfügung auf die im Kapitel 3 auf Seite 7 näher eingegangen wurde. 4.3 jdb-kommandos Die folgende Liste zeigt einige möglichen Kommandos, die der jdb Debugger zur Verfügung stellt.

17 4.3. JDB-KOMMANDOS 12 Basis jdb-kommandos!! Der zuletzt eingegebene Befehl wird nochmals wiederholt.? Zeigt ein Liste aller Kommandos classes Gibt die Namen und ID s der Klassen aus, die bereits geladen sind. down< n > Der aktuelle Stack-Bereich eines Threads wird um n Frames nach unten gesetzt. Ohne Parameter wird das Frame um eine Einheit nach unten bewegt. dump Für einfache Datentypen hat dieses Kommando den selben Effekt wie print. Bei Objekten wird die aktuelle Variable von jeden Feld ausgegeben. run Nach dem Starten des jdb und dem Setzen von eventuellen Breakpoints, kann man mit run das Ausführen der Applikation starten. Dieses Kommando steht nur zur Verfügung, wenn jdb die Applikation ausführt. Nicht aber, wenn eine Verbindung zu einer anderen Virtuellen Maschine aufgebaut wurde. cont Fährt mit der Ausführung weiter nach Breakpoints, Exceptions oder Steps. print Zeigt Java TM Objekte und einfache Datentypen. Bei Variablen und Feldern von einfachen Datentypen wird der Wert der Variablen ausgegeben, währen bei Objekten ein kurzer Beschrieb angezeigt wird. threads Zeigt alle aktuellen Threads auf, wobei jeweils der Name und der aktulle Status ausgegeben werden, wie auch der Index den man für weitere Kommandos benötigt. thread Wird verwendet, um ein Thread zu selektieren und zwar mit Hilfe der Indexes, die man mit dem threads Kommando erhält. where Ohne Argumente zeigt where den Inhalt des aktuellen Thread an. where all zeigt den Stackinhalt aller Threads der aktuellen Threadgruppe an. where threadindex zeigt den Inhalt des gewünschten Thread an. Falls der aktuelle Thread suspendiert ist, entweder durch einen Breakpoint oder mit Hilfe des suspend Kommando, können lokale Variablen und Felder angezeigt werden. Breakpoints Das Setzen von Breakpoints sieht bei dem jdb folgendermassen aus: Entweder man setzt den Breakpoint beim Beginn einer Methode, oder einfach auf der gewünschten Zeile in einer Klasse. stop at MyClass:22 Setzt den Breakpoint bei der ersten Instruktion auf der Zeile 22. Die Klasse darf aber nicht mit java -O übersetzt werden, da sonst die Zeilennummern fehlen.

18 4.4. KOMMANDO ZEILEN OPTIONEN 13 stop in java.lang.string.length Setzt den Breakpoint beim Beginn dieser Methode clear< class : line > Entfernt Breakpoints, die in der angegebenen Zeile in der entsprechenden Klasse gesetzt waren. Der Aufruf ohne Parameter generiert eine Angabe aller gesetzten Breakpoints. cont Der aktuell unterbrochene Thread wird fortgesetzt. Wenn eine Methode überladen wurde, müssen zusätzlich noch die Argumente der entsprechenden Methoden angegeben werden, um einen Breakpoint zu setzten. Stepping Das step Kommando führt die nächste Linie aus, egal ob es sich um ein aktuellen Stack Frame oder einen Methodenaufruf handelt. Während das next Kommando dazu führt, dass die nächste Zeile im aktuellen Stack Frame abgearbeitet wird. Weiter führt step up dazu, dass die aktuelle Methode ausgeführt und dann zum Methodenaufruf zurück gekehrt wird. step in hingegen führt einfach nur die aktuelle Instruktion aus. Exceptions Falls in einem Java TM Programm eine Exception geworfen wird die nicht mit einem catch Statement abgefangen wird, wird normalerweise die Exception ausgegeben. Falls das Programm unter jdb läuft, wird diesem die Kontrolle übergeben und man hat die Möglichkeit die Exceptions abzufangen. So wird die Applikation, die man debuggt, falls eine spezifische Exception geworfen wird gestopt. Das Kommando catch java.io.filenotfountexception führt also dazu, dass jede Exception welche eine Instanz dieser Klasse oder einer Subklasse ist, die Applikation an dem Punkt an dem sie geworfen wird stopt. 4.4 Kommando Zeilen Optionen Falls man eine Java TM -Applikation mit dem jdb ausführt, hat man nebst vielen Optionen, die man auch beim normalen java Kommando hat, noch einige zusätzliche Optionen. Einige davon sind: -help Zeigt die Help an -sourcepath< dir1 : dir2 :.. > Falls die Sourcefiles nicht im aktuellen Verzeichnis sind, können mit dieser Option die Entsprechenden Verzeichnisse angegeben werden.

19 4.5. TESTVERSUCHE MIT JDB 14 -attach< address > Verbindet den Debugger mit einer bereits gestarteten Virtuellen Maschiene. -listen< address > Wartet auf eine Virtuelle Maschine, um via Default- Verbindung, zur spezifizierten Adresse eine Verbindung aufzunehmen. -listenany Wartet auf eine Virtuelle Maschine, um via Default-Verbindung, sich mit einer beliebigen Adresse zu verbinden. -launch Die zu debuggende Applikation wird sofort gestartet. Wodurch es nicht mehr nötig ist mit dem run Kommando zu starten. Die Applikation wird ausgeführt und dann gestoppt, bevor die Initialisierungsklasse geladen wird. An diesem Punkt hat man die Möglichkeit, Breakpoints zu setzten und dann mit dem cont Befehl das Ausführen fortzufahren. -connect< connector name >:< name1 >=< value1 >,.. Stellt eine Verbindung zur Ziel VM her. -dbgtrace Gibt Informationen über jdb aus. 4.5 Testversuche mit jdb Debugging eines Servlet Ein Servlet debuggt man am einfachsten in dem man die Servlet Engine im Debug Modus startet. Für den Tomcat 4.0 kann man zum Beispiel das Catalina File abändern und bei den Start Optionen noch zusätzlich folgende Optionen angeben: -Xdebug -Xrunjdwp:transport=dt_shmem,address=jdbconn,server=y,suspend=n Auf die Servlet Engine kann jetzt also via Shared-Memory, über die Adresse jdbconn, zugegriffen werden. Wir starten den Tomcat also folgendermassen mit Hilfe des abgeänderten catalina Files: C:\Program Files\Apache Tomcat 4.0\bin>catalina start Im Anhang A auf Seite 17 wird eine mögliche Servlet Debugg Session gezeigt. Remote Debugging Einer der grossen Vorteile der JDPA-Architektur ist die Möglichkeit eine Applikation, die auf einem remote Rechner läuft, via Sockets, zu debuggen. In diesem Beispiel möchte ich zeigen wie man die Server-Applikation der virtuellen Bank debuggen kann. Ich logge mich via Telnet ein und starte den Server folgendermassen!

20 4.5. TESTVERSUCHE MIT JDB 15 java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n server.server Listening for transport dt_socket at address: Nun kann ich den Debugger starten, um den Sever von meiner Maschine aus zu debuggen: jdb -connect com.sun.jdi.socketattach:port=32927,hostname=mr6550b.cs.fh-aargau.ch

21 Schlusswort Basierend auf der Java TM Plattform Debugger Architektur hat man enorme Möglichkeiten, um Debugger oder ähnliche Applikationen, die das ausführen eines Programmes überwachen oder beeinflussen sollen, zu bauen. Der Java TM Debugger jdb, der als Demonstration der Java TM Platform Debugger Architektur betrachten werden kann, ist ein Tool welches sich in vielerlei Hinsicht bei der Entwicklung als nützlich erweisen wird. An dieser Stelle möchte ich mich bei dem betreuenden Dozenten Herrn Prof. Dr. Dominik Gruntz, herzlich für seine Unterstützung bedanken. Felix Frei Windisch, 16. Mai 2002

22 Anhang A Beispiel debugging eines Servlet Eine Debug Session für ein Servlet sieht zum Beispiel folgendermassen aus: F:\jdb\Batch>jdb -attach jdbconn Initializing jdb... > threads Group system: (java.lang.ref.reference$referencehandler)0x3 Reference Handler cond. waiting (java.lang.ref.finalizer$finalizerthread)0x4 Finalizer cond. waiting (java.lang.thread)0x5 Signal Dispatcher running (java.lang.thread)0x6 CompileThread0 cond. waiting Group main: (java.lang.thread)0x1 main running (java.util.logging.logmanager$cleaner)0xb Thread-0 unknown (java.lang.thread)0xc WebappLoader[/library] cond. waiting (java.lang.thread)0xd StandardManager[/library] cond. waiting (java.lang.thread)0xe WebappLoader[/examples] cond. waiting (java.lang.thread)0xf StandardManager[/examples] cond. waiting (java.lang.thread)0x10 WebappLoader[/servletbank] cond. waiting (java.lang.thread)0x11 StandardManager[/servletbank] cond. waiting (java.lang.thread)0x12 StandardManager[/manager] cond. waiting (java.lang.thread)0x13 StandardManager[] cond. waiting (java.lang.thread)0x14 StandardManager[/soap] cond. waiting (java.lang.thread)0x15 StandardManager[/tomcat-docs] cond. waiting (java.lang.thread)0x16 StandardManager[/webdav] cond. waiting (java.lang.thread)0x17 HttpConnector[8080] running (java.lang.thread)0x18 HttpProcessor[8080][0] running (java.lang.thread)0x19 HttpProcessor[8080][1] cond. waiting (java.lang.thread)0x1a HttpProcessor[8080][2] cond. waiting (java.lang.thread)0x1b HttpProcessor[8080][3] cond. waiting (java.lang.thread)0x1c HttpProcessor[8080][4] running (java.lang.thread)0x1d Thread-1 running > thread 0x10 WebappLoader[/servletbank][1] stop at ServletBank:47 Set breakpoint ServletBank:47 WebappLoader[/servletbank][1] Breakpoint hit: "thread=httpprocessor[8080][4]", ServletBank.doGet(), line=47 bci=216 HttpProcessor[8080][4][1] print name name = "Meier" HttpProcessor[8080][4][1] set name="fischer" name="fischer" = "Fischer" HttpProcessor[8080][4][1] print amount

23 18 amount = "200" HttpProcessor[8080][4][1] list Source file not found: ServletBank.java HttpProcessor[8080][4][1] use C:\Program Files\Apache Tomcat 4.0\webapps\servletbank\WEB-INF\classes HttpProcessor[8080][4][1] list 43 name = request.getparameter("name").trim(); 44 amount = request.getparameter("amount").trim(); if (name!= null && amount!= null &&!name.equals("") &&!amount.equals("")) { 47 => try { 48 number = bank.createaccount(name); 49 my = bank.getaccount(number); 50 my.deposit(double.parsedouble(amount)); 51 out.println("<h3>" + "create Account successful!" +"</h3>"); 52 } catch (IOException e) { HttpProcessor[8080][4][1] dump my my = null HttpProcessor[8080][4][1] next > Step completed: "thread=httpprocessor[8080][4]", ServletBank.doGet(), line=48 bci= number = bank.createaccount(name); HttpProcessor[8080][4][1] next > Step completed: "thread=httpprocessor[8080][4]", ServletBank.doGet(), line=49 bci= my = bank.getaccount(number); HttpProcessor[8080][4][1] next > Step completed: "thread=httpprocessor[8080][4]", ServletBank.doGet(), line=50 bci= my.deposit(double.parsedouble(amount)); HttpProcessor[8080][4][1] dump my my = { number: "1" name: "Fischer" active: true balance: } HttpProcessor[8080][4][1] where [1] ServletBank.doGet (ServletBank.java:50) [2] ServletBank.doPost (ServletBank.java:197) [3] javax.servlet.http.httpservlet.service (HttpServlet.java:1 145) [4] javax.servlet.http.httpservlet.service (HttpServlet.java:1 264) [5] org.apache.catalina.core.applicationfilterchain.internaldofilter (ApplicationFilterChain.java: 247) [6] org.apache.catalina.core.applicationfilterchain.dofilter (ApplicationFilterChain.java:193) [7] org.apache.catalina.core.standardwrappervalve.invoke (StandardWrapperValve.java:243) [8] org.apache.catalina.core.standardpipeline.invokenext (StandardPipeline.java:566) [9] org.apache.catalina.core.standardpipeline.invoke (StandardPipeline.java:472) [10] org.apache.catalina.core.containerbase.invoke (ContainerBase.java:943) [11] org.apache.catalina.core.standardcontextvalve.invoke (StandardContextValve.java:215) [12] org.apache.catalina.core.standardpipeline.invokenext (StandardPipeline.java:566) [13] org.apache.catalina.valves.certificatesvalve.invoke (CertificatesValve.java:246) [14] org.apache.catalina.core.standardpipeline.invokenext (StandardPipeline.java:564) [15] org.apache.catalina.core.standardpipeline.invoke (StandardPipeline.java:472) [16] org.apache.catalina.core.containerbase.invoke (ContainerBase.java:943) [17] org.apache.catalina.core.standardcontext.invoke (StandardContext.java:2 366) [18] org.apache.catalina.core.standardhostvalve.invoke (StandardHostValve.java:164) [19] org.apache.catalina.core.standardpipeline.invokenext (StandardPipeline.java:566) [20] org.apache.catalina.valves.accesslogvalve.invoke (AccessLogValve.java:462) [21] org.apache.catalina.core.standardpipeline.invokenext (StandardPipeline.java:564) [22] org.apache.catalina.core.standardpipeline.invoke (StandardPipeline.java:472) [23] org.apache.catalina.core.containerbase.invoke (ContainerBase.java:943) [24] org.apache.catalina.core.standardenginevalve.invoke (StandardEngineValve.java:163)

24 19 [25] org.apache.catalina.core.standardpipeline.invokenext (StandardPipeline.java:566) [26] org.apache.catalina.core.standardpipeline.invoke (StandardPipeline.java:472) [27] org.apache.catalina.core.containerbase.invoke (ContainerBase.java:943) [28] org.apache.catalina.connector.http.httpprocessor.process (HttpProcessor.java:1 005) [29] org.apache.catalina.connector.http.httpprocessor.run (HttpProcessor.java:1 098) [30] java.lang.thread.run (Thread.java:536) HttpProcessor[8080][4][1] cont >

25 Literaturverzeichnis [1] Sun Microsystems Java TM Platform Debugger Architecture Main Site Stand [2] Sun Microsystems Java TM Platform Debugger Architecture (JPDA) Stand [3] Sun Microsystems Java TM Virtual Machine Debug Interface (JVMDI) Stand [4] Sun Microsystems Java TM Debug Wire Protocol (JDWP) Stand [5] Sun Microsystems The Java TM Debug Interface (JDI) Stand [6] Sun Microsystems Connection and Invocation Details Stand [7] Sun Microsystems jdb - The Java TM Debugger Stand [8] NATHAN L. FIEDLER JSwat Project Home Page Stand