Lab 3

CS 1005, C-term 03

January 29, 2003

Problem

The goal of this lab is to give students practice finding errors using a debugger program: gdb. You will be given a program that contains both syntax and logical errors. Your job is to find and fix the ``bugs'' so that the program runs correctly.

Syntax errors are the ``grammatical'' kinds of errors found by the compiler. However, even though a program compiles correctly it may still contain errors in logic. A debugger program is the tool to use to help you find the logical errors.

What you should do...

1. Sign the attendance sheet.
2. Copy the buggy file (lab3.cxx) and the data file (lab3.data), into your directory as follows. (Note that the 'cp' command has a space and a '.' at the end of it).

   > cp /cs/cs1005/labs/lab3/* .
   

3. Compile lab3.cxx using the command given below to get a list of the errors found by the compiler. Fix the syntax errors and compile again. The -g in the compile command tells the compiler that you might use the debugger later.

   > g++ -g lab3.cxx
   

4. After the program compiles, try running it and examine the output. When the program runs correctly, the output should look like this:

   Entering daily noon temps
   
   Out of 5  days:
   There are 1 hot days
   There are 2 pleasant days
   There are 2 cold days
   The average temp is 73.8
   
   This is NOT a perfectly pleasurable climate.
   

   Carefully read the comments in the program so that you understand what the program is supposed to do. Unless you happened to catch all of the logical errors as well as all the syntax errors, your program probably does not give you that output. The program gdb (Gnu DeBugger) lets you run your program in a controlled way, one command at a time, so you can see exactly what's going on. Here are some useful gdb commands:

           help                    help
           list                    display ten more lines
           list  <line number>     display ten lines centered around 
                                   <line number>
           list -                  display ten lines previous to the lines
                                   just printed 
           print <variable name>   print the value of a variable
           break <function name>   set a breakpoint at the start of a function
           break <line number>     set a breakpoint at the specified line
           cont                    continue execution after a breakpoint
           clear <function name>   remove all breakpoints from function
           run                     run program with optional arguments
           step                    resume execution for just a single statement
           quit                    exit the debugger
           backtrace               shows layers of functions you are into
   

5. Start the debugger by typing gdb a.out. You'll see a welcoming message followed by the debugger's prompt:

   (gdb)
   

   Once you're in the debugger, you can use any of the gdb commands given above to interrupt execution of your program, and to examine the values of variables. I suggest you use the following gdb commands to help you trace the execution of the main program loop:

   list

   displays your source code with line numbers

   break

   places a breakpoint at the given line number (try placing a breakpoint at a statement inside the loop so you can check the values of the variables each time through the loop)

   run

   starts program at the beginning and runs until it encounters your breakpoint

   print

   prints the value of the given variable (look at temp and totalTemp)

   cont

   picks up execution from the breakpoint, and stops when it encounters the next breakpoint

6. When you have tracked down and obliterated the bugs and gotten the program to run correctly, make a script file showing the output of the program. Name your script file lab3.script.
7. Turn in the working lab3.cxx and a script file, using the following command line:

      /cs/bin/turnin submit cs1005 lab3 lab3.cxx lab3.script
   

8. Save this lab page! Out of necessity, the program you debugged today was very simple. You may be thinking that you could more easily debug this program just by looking at it. As your programs become more complicated and harder to debug, you will appreciate the value of a tool like gdb. Type man gdb at the Unix prompt if you would like more information about gdb.