Kalimantan - Debugger

How To

Debug an application

1. make sure the kalimantan bin directory is in your path
2. invoke your application with jed instead of java (if you're running on a Windows machine, then the jed script won't work. Replace jed with java dstc.kalimantan.debug.Main in the lines both above and below).
3. you should now have a debugger window (see window tour below), from which you may set breakpoints and run the application

Debug a remote application

1. once again, make sure the kalimantan bin directory is in your path
2. start the application you wish to debug using java_g instead of java. It will print a password string, like so:

   $ java_g -debug ListTest
   Agent password=amdbz
   

3. invoke jed using the hostname and password, thusly:

   $ jed -host sequoia.dstc.edu.au -password amdbz
   

4. if all has gone well the application and debugger should both have appeared on your screen.

Debug an applet

Do everything you need to debug an application except that instead of invoking an application, invoke the applet, thusly:

Window Tour

The first debugger window you see will be the thread monitor, shown below:

The left hand list shows thread groups, the right hand list shows the threads in the currently selected group. The status of the thread (suspended, running, idle, cond.waiting, etc.) is shown in parentheses.

The Run button will start the application named when the debugger was invoked. The Breakpoints button allows you to set and clear breakpoints at the start of a given method. The Show button opens a debugger on the selected thread.

Setting Breakpoints

You set a breakpoint by filling in the class and method names and pressing Set Breakpoint. It should then appear in the list of breakpoints on the left. To remove the breakpoint, select it in this list and then press the Clear Breakpoint button.

Using the Thread Debugger

• the two buttons at the top left can be used to start and stop the thread.
• the leftmost list (beneath the buttons) gives a stack trace when
• the three buttons at the bottom left are used to control stopped threads (at a breakpoint).
• the center panel shows the current point of execution in the source code
• on the right are two inspectors
  • the top inspector shows the instance variables of the current object (in this case, WWWItemClass)
  • the bottom inspector shows the local variables of the current method (in this case, WWWItemClass.updateDisplay)

Thread Control Buttons

Step executes the next instruction in the current thread, descending deeper into the stack if necessary. Next behaves like Step except that it won't descend into the stack. Continue continues normal execution after a breakpoint. Don't use these buttons on threads which are suspended (see Bugs below).

Known Bugs

• Don't step suspended threads. If you step or continue a suspended thread in the thread debugger, bad things happen.
• Don't resume from breakpoints. If you resume from a breakpoint (instead of continuing) it won't restart the other threads properly.
• No source code. The debugger uses your classpath of the client application in order to locate source code. If you keep seeing "source code not available" when you know that it is, try modifying the CLASSPATH environment variable and restarting everything.