Your goal here is to get to know gdb, a "debugger" program that can help you find the problems with your programs. Debuggers can't help you until your program compiles, but once you have eliminated all compiler errors, a debugger can be one of your most valuable tools.
Today, you'll use gdb to (1) watch a variable, (2) single-step through a program, and (3) set breakpoints. All three of these operations should become clear shortly.
Save the program odds.cpp in your account, and compile it as follows:
g++ odds.cpp -g -Wall -o odds
The -g flag tells the compiler to include debugging information in the executable file "odds".
Open odds.cpp in your editor, and move the window off to the side.
In the terminal window, run the command
gdb odds
At the gdb prompt, type "list". You should see the first 10 lines of your program. Type "list" again. You should see the next 10 lines. Next, type "list 8". You should see the lines of code around line 8.
Line 7 should be the one that reads "int N = 10". Set a breakpoint on this line by typing "break 7" at the gdb prompt.
Run the program by typing "run" at the gdb prompt. The program will run until your breakpoint and stop there.
Type "print N" at the gdb prompt. Also do "print sum" at the gdb prompt. What values are currently in N and sum? Why?
At the gdb prompt, type "step". What happens? What is the value of N now? What is the value of "sum" now?
Keep stepping your code. How do N and sum change as you move through your code?
Run the program again, but this time type "next" instead of "step" to move through your program. What is the difference between "next" and "step"? Why is this useful for debugging?
Run the program again, and this time use "step" again to step into the SumOfOdds function. After you have stepped through a couple of iterations of the while loop, type "cont" at the gdb prompt. What does this command do? Why is this useful for debugging?
Type "help list" or "help step" or just "help". There's lots more information available. Type "quit" to quit.
Try gdb on one of your own programs. Note that you can list the code in a member function by typing something like "list Queue::Add".
There's an interesting tutorial on gdb by Andrew Gilpin at http://www-2.cs.cmu.edu/~gilpin/tutorial/. He guides you through the discovery of the cause of a segmentation fault in a templated linked list class. If you want more experience with gdb, check it out.
You can also take a look at the official gdb documentation.
Your goal here is to get to know insure, another debugging tool that will help you find memory errors in your programs.
Save the program lotsobugs.cpp in your account, and compile it with the -g flag.
Run the program by typing "lotsobugs" at the command prompt. What happens? Why?
Log onto prism, our main Linux server. To do this, type:
ssh prism
at the Linux prompt (insure is only available from prism).
Recompile your program using insure instead of g++ like this:
insure lotsobugs.cpp -g -Wall -o lotsobugs
(Note: If you see the error "insure: Command not found", this means that your account was not set up to use insure by default. You can repair this problem by typing:
source /usr/local/bin/setup-parasoft
You'll need to do this once inside any terminal window for which you want to run insure.)
Run your program by typing "lotsobugs" at the terminal window. What happens? Using the information you get from insure, fix the bugs in the code one by one, recompiling each time. What kinds of errors does insure tell you about? (Fixing the errors one at a time starting at the top is important, because new errors will appear as you do so, and you want to make sure to see all the error messages lotsobugs can show you.)
Read through the description of makefiles at http://www.mathcs.carleton.edu/courses/course_resources/cs117/project-management/index.html.
Set up a Makefile for lotsobugs.cpp that has three options: compiling without debugging flags, compiling with debugging flags, and using insure.
Test your Makefile.
For this part of the lab, your goal as a class is to find as many different insure error messages as possible, and list them along with their causes.
Start with one of the programs you have written or one of the lab exercise programs. Introduce a small error into it. Write down the error you introduced, and the error message insure generated. We'll make a master list on the white board.
Be creative, and have fun.
Based on an original document by Mark Peralta, modified by Jeff Ondich, enhanced by Dave Musicant, and adapted yet again by Jeff Ondich. Who's next?
Jeff Ondich, Department of Mathematics and Computer Science, Carleton College, Northfield, MN 55057, (507) 646-4364, jondich@carleton.edu