The java System.out.println statement is and effective way to debug a program. Placing “debugging printouts” throughout the program at critical places to monitor the execution can be helpful. These printouts can easily be commented out when the debugging is completed, and later uncommented if further bugs show up later.

But what to do when this becomes too tedious? Another option is to use a debugger, such as jdb. We’ll go through an example which takes you through some basic debugging tasks. This tutorial goes through using the text version of the debugger. At the completion of the tutorial you should be comfortable enough with the different debugging techniques. For those students that want the debugger to be a little more visual, there is a further tutorial that teaches you how to integrate jdb and Emacs together into a development tool (see the bottom of this tutorial).

• Say there was some problem in our factorial program and you were pretty sure the problem had to do with the recursion. The debugger would be very useful in allowing you to step through the code, and show you the intermediate values being generated at each recursive call. To get an idea of how to do this, let’s step through the code for an input of 4. To run jdb on the file named fact.class with an input of 4, type :
  

  jdb fact 4
  

• You will see some output about jdb being initialized, and then you should see the command prompt “> “
• If you type help, you will be given a list of the debugger commands along with a short description of what they do.
• The first thing to do is set a break point at the very start of the program so that when it is run, you can step through the application. The stop in and stop at commands allow you to set breakpoints in the program. Type in the following to set a break point at the first line of the main method:
  

  stop in fact.main
  

• Now start the program running by typing
  

  run
  

• Now the program is being run, and it is temporarily halted. To see where in the code the program is halted you type
  

  list
  

  It shows you the source code around the next instruction to be executed (indicated by the =>).

• Now we want to set a breakpoint after the preamble of the program that converts the input to a number. If you type list 55 you will see the code that calls the Factorial routine. Set the next breakpoint by typing stop at fact:55.
• Type cont to continue running to the breakpoint.
• Now we want to step into the Factorial routine. Type step. You will see a message saying that the breakpoint for the java.lang.ClassLoader.loadClass was hit. This is some auxiliary code that you are not interested in. Type step up to get back to the main routine, and type step again to get inside the Factorial method.
• To take a look at the variables inside the method (those that have been set) type locals. You should see the value of 4 for the num variable passed in.
• Type step again, and type in locals. This time you should see the values for both num and calc. The last instruction set the local variable calc to 0, so now it appears in the list. You can see that by typing in the list command.
• Keep stepping through the code looking at the variables after each recursive call. You will see the value of num being decremented each iteration. Keep doing this until finally you step into the line of code that sets the return value to 1 (calc = 1;). Again, the list command will help you keep an eye on where in the code you are. Step over that line of code and look at the locals now: calc has changed to 1.
• At this point it is worth noting that the up and down commands allow you to go up and down the call stack to look at the values of the local variables in the methods that called the current one. For instance, typing up and locals will show you the previous iteration of the Factorial recursion (with num = 2). Don’t forget to type down to return the stack frame to the bottom of the calling stack.
• Continue to type step and type locals to watch the value of calc grow (factorially) as each recursive call returns.
• Finally you will return to the main procedure. You will know this by the output of:
  

  Breakpoint hit: fact.main (fact:55)
  

  At this point we just want the program to run to completion, so simply type cont. The program will print the output of 24 to the screen, and the program/debugger will quit.

• Run the program a couple more times and try to play with the other commands. If you type man jdb from the Unix prompt, you will be presented with a little more detail about how the commands work.

Test Your Debugging Skills

Now it’s time to try your hand at debugging some code. We will now look at the fib.java program which produces the desired Fibonacci number using the same recursive method as the last program. However, there are two errors in the program. The first is a bug that prevents the program from properly compiling, and the other is a logic error in the code.

• Try to compile the Fibonnaci program:
  

  javac -g fib.java
  

• You will receive an error message describing an error at line 15 pertaining to fact not being declared. Open up the program with your favourite editor and go to line 15. In Pico, you can find out what line you are on by pressing Ctrl-C in the editor. The message indicated that there is a problem with this declaration. Do you see the problem? Fix the error and save the changes. In case you can’t figure out the error, the answer appears at the bottom of this document.
• Now compile the program and run the program by typing java fib 0
• Run the program with an input of 0 and 1. So far so good. Now run the program with an input of 4. You will see an unending streak of errors, with no indication of where the error is. Press Ctrl-C to kill the program (it may take a few seconds).
• Now it’s time to play detective. Load up the debugger and step through the code for the calculation of the Fibonacci number (just like you did last time), and see if you can narrow down the problem. There is only 1 tiny bug in the actual code. Once again, there is a hint that appears at the bottom of the tutorial, but you should be able to solve the problem on your own.
• Make the change to the code and recompile and test the change. Does your program produce an output of 8 for in input of 6?

db2 -r out.txt

more help type:  ? options inside the db2 console

find ./ -iname \*.mp3  cp {} /home/user/song \;

if p | ab

=> p | a or p | b

proof by contradiction:

assume p is not divided by a and p is not divided by b

p | ab =>  gcd(p, a) = 1  =>  xp + ya = 1  such that there exists x, y in Z(Eculidan algorithm)

since xp + ya = 1 => b(xp + ya) = b  =>  bxp + bya = b

since a | ab = > p | bya  and p | bxp

=> p | (bxp + bya)   => p | b

that contradict to our assumption

db2 -f mybatch.txt

db2=> list tables for all

// list table tb1

db2=> list tables for scheme tb1

how to prove 3Z is subring of Z (Z is integer)

we only need to prove 3Z is closed under subtraction and multiplication.

subtraction => 0 and additive inverse in the 3Z.

let a, b in 3Z.

if a – b in 3Z then

let a = b, =>  b + (-b)  = in 3Z

=> 0 in 3Z and additive inverse -b in 3Z

if R is a Ring and I is subring of R, then

if r in I, and x in R then

r*x in I and x*r both in I

example of Ideal:

let R = Z, I = 2Z

r in Z

x in 2Z

then r*x = z*2Z = 2*Z

x*r = 2Z*Z = 2*Z

hence  2Z is an Ideal

[ad] Empty ad slot (#1)!