Debugging with Java 1.2

Example from Sun to try first:

Debugging the TicTacToe Applet

--------------------------------------------------------------------------------

Start the appletviewer in "-debug" mode, specifying an HTML file with the applet to debug. If you have problems, make sure you can first run the applet without the "-debug" flag. jdb will start, and report that the sun.applet.AppletViewer class is loaded.
Type "threads" to show the thread running at startup.
Type "run" to start the AppletViewer.
After the TicTacToe applet is displayed, type threads again. This time, two threadgroups will be displayed: one for the AppletViewer and one for the TicTacToe applet. Although all threads are running, try examining the threads and classes as in the previous tutorial.
To set a breakpoint, type "stop in TicTacToe.mouseUp". The "stop in" command sets a breakpoint at the first Java bytecode in the specified method. The "stop at <class:line>" will stop at the first bytecode generated by a particular line in a Java source file.
Click on a square in the TicTacToe applet. jdb will stop the applet's execution at the breakpoint just set. Type "where" to show the applet's stack. Type "threads" to see that the current thread is at a breakpoint, and the other threads suspended.
Type "step" to execute the first line in mouseUp(). Notice how it entered the status() method. Step again to execute additional lines.
Type the "use" command to see the path list jdb uses to find source files (by default, the classpath). Type "list" to view the current source. If TicTacToe.java isn't in your class path, change the source path list using "use <path list>".
Type "up" to examine the previous stack frame (mouseUp()). Type "list" again to view its source." Type "down" to go back to the status() stack frame.
To see the local variables, type "locals", or the name of the variable (use "this" to print the object whose method we are stopped in). If no local variables are available, try this tutorial again after re-compiling the TicTacToe applet using the "-g" option.
Type "cont" to continue execution from the breakpoint. Click another TicTacToe square to show that the breakpoint is still active.
The breakpoint message shows the line number of the breakpoint. Try clearing that breakpoint with "clear TicTacToe <line number>. Type "cont" and click another TicTacToe square to verify that the breakpoint is cleared.


I believe also the following VM invocation options are required to debug applications running under the classic VM.

-Xdebug
Enables debugging
-Xnoagent
Disables the old sun.tools.debug agent. JPDA attaches its "agent" in a different manner, described below.
-Djava.compiler=NONE
Disables the JIT compiler. Debugging with the classic VM requires that it's JIT compiler be disabled.
-Xrunjdwp:<sub-options>
Loads the JPDA reference implementation of JDWP. This library resides in the target VM and uses JVMDI and JNI to interact with it. It uses a transport and the JDWP protocol to communicate with a separate debugger application. Specific sub-options are described below.

There is also some more general info here:

http://java.sun.com/products/jdk/1.1/debugging/

Hope this helps...

chk out,
http://www.metamata.com/products/debug_top.html

Hi sqoms, I do not want to purchase another debugging tool, I am already using Visual Age distributed debugger.

Hi Jod,

many thanks to your huge answer. My problem is more straight, that the Java 1.2 VM on Solaris just prints to cited error message and sadly does _not_ include the 'java_g'; I found a 'java_g' in version 1.1.6 on AIX as an old relict of former times - I want to debug Java 1.2 with the sun.tools.agent.Agent class.

Supplying 'Xnoagent' works, but I _need_ the agent, I think.


Do you have any other Idea of how to debug Java 1.2 Servlets on a Solaris machine, started from Apache JServ ?

Maybe it's more difficult than I thought, I'll increase to 200 Pts.

Also, because it is a bit hidden away in the details above this comment is just to point out that if you compile using the -g option you will enable maximum visibility of program details to the debugger.

-g generates all debugging information, including local variables. By default, only line number and source file information is generated.

It's fine

thanks to Jod !
I think I'll can go much deeper into dubugging with this info !