- Compiler Errors versus Logic Errors
- What jdb Brings to the Table
- Enough Introduction...Let's Debug Already!
- Some Advanced Notes about Debugging
- Resources
- Conclusion
Enough Introduction...Let's Debug Already!
You start up your debugging session by using a specialized version of the Java interpreter. To debug a Java class, simply invoke the jdb tool with the name of the Java class you want to debug as an argument:
jdb YourClassName
The syntax above would run jdb on the class named YourClassName.class. Doing so runs the program using a special version of the Java interpreter that the debugger can interact with.
We Need Something to Debug
For purposes of studying jdb's offerings, we will use jdb on the Java class shown in Listing 1. (You can download this class here.) Although we are trying to troubleshoot a Java class, you need to make sure that jdb has access to both the .class file of you Java class as well as the source code of the class (that is, the .java source file).
Listing 1 The DebugMe class
1 public class DebugMe {
2 public static void main(String[] args) {
3 DebugMe debugMe = new DebugMe();
4 System.out.println("Example program for debugging");
5 int a = 10;
6 int b = 7;
7 int c = debugMe.adder(a, b);
8 System.out.println("Result= " + c);
9 }
10 public int adder(int x, int y) {
11 System.out.println("Adding " + x + "+" + y);
12 int z = x + y;
13 return z;
14 }
15 }
Our class is intentionally kept simple. We have a simple adder method that adds two incoming integers and returns the sum. You'll see later why I structured the code the way I did. It is designed to demonstrate the usage of the debugger.
Compiling to Get More Info
When you want to debug an application, you need to compile your class using the –g option. This compile option specifies that extra information be added to the class file that is generated. This extra information is used in the debugging process. The –O option should not be used when compiling a class you want to debug. Using –O means that you want to optimize your class file. This optimization process might render a class file that does not necessarily match up with the class file's source code, thus not allowing us to use the debugger properly.
Let's Do Some Debugging
We can set breakpoints
At specific line numbers of the source code
When a method is called
When an exception is caught
Let's fire up the debugger for the class shown in Listing 1 with this command:
C:\j2sdk1.4.2_03\bin>jdb DebugMe Initializing jdb ... >
It is at the > prompt that we control our debugger.
Setting Breakpoints
We can set a breakpoint at the method level by using this syntax:
stop in classname.methodname
So in our case, we can use this command:
stop in DebugMe.adder
Doing this, you will see a response of the following to specify that we want a breakpoint at the first line of the adder method of the DebugMe class:
> stop in DebugMe.adder Deferring breakpoint DebugMe.adder. It will be set after the class is loaded.
Similarly, we can specify that we want to add a breakpoint to a specific line number by using this syntax:
stop at classname:lineNumber
If we want to have a breakpoint at line number 7, we would use the following command:
stop at DebugMe:7
Listing and Clearing Breakpoints
You can list all the breakpoints you set by using the clear command with no arguments.
For our work above, we would see the following response:
> clear
Breakpoints set:
breakpoint DebugMe.adder
breakpoint DebugMe:7
If we want to remove a breakpoint, we can use this syntax:
clear classname:lineNumber
NOTE
Note that if you set your breakpoint using the stop in syntax (that is, setting at method level), you still need to specify the line number where the method begins if you want to remove it.
Beginning Execution
We begin the execution of the program by using the run command at the prompt. When we do so, we see the following:
> run run DebugMe Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint DebugMe:7 Set deferred breakpoint DebugMe.adder Example program for debugging Breakpoint hit: "thread=main", DebugMe.main(), line=7 bci=22 7 int c = debugMe.adder(a, b);
Now that we have hit a breakpoint, we can enter some commands:
locals: As shown below, locals shows us the local variables currently in use and their values:
main[1] locals Method arguments: args = instance of java.lang.String[0] (id=270) Local variables: debugMe = instance of DebugMe(id=271) a = 10 b = 7
Notice that because the breakpoint was defined at line 7, line 7 has not yet executed. Accordingly, we are not shown variable c because it has not been created.
print name: Shows us the value of the variable or object specified by name. If, for example, we want to see the contents of variable a:
main[1] print a a = 10
list: Shows some of the source before and after where the breakpoint was set. Pay particular attention to "=>", which shows where the execution is paused:
main[1] list
3 DebugMe debugMe = new DebugMe();
4 System.out.println("Example program for debugging");
5 int a = 10;
6 int b = 7;
7 => int c = debugMe.adder(a, b);
8 System.out.println("Result= " + c);
9 }
10 public int adder(int x, int y) {
11 System.out.println("Adding " + x + "+" + y);
12 int z = x + y;
Using the command cont, we can continue the running of the program until another breakpoint is hit. Notice that the debugger moves into the adder method because we specified a breakpoint there earlier:
main[1] cont
>
Breakpoint hit: "thread=main", DebugMe.adder(), line=11 bci=0
11 System.out.println("Adding " + x + "+" + y);
The step command allows us to move to the next line and pause execution there. Take a look at the portion of the debugging session below; we perform a series of steps followed by locals to show how our program is executed line by line, and how our local variable values are affected after each line is executed:
main[1] step > Adding 10+7 Step completed: "thread=main", DebugMe.adder(), line=12 bci=34 12 int z = x + y; main[1] locals Method arguments: x = 10 y = 7 Local variables: main[1] step > Step completed: "thread=main", DebugMe.adder(), line=13 bci=38 13 return z; main[1] locals Method arguments: x = 10 y = 7 Local variables: z = 17
The exit command can be used any time in the debugger to end the debugging session.