CS 54 - Lab 13

Introduction & Warnings

Today we will be looking at debugging tools and techniques that can be used both in UNIX and Windows. What that means is, you will be dealing with code that has bugs intentionally written into it and may go into infinite loops if you're not careful. Here are the well- and lesser-known ways to stop a UNIX program from going out of control:

**UNIX Panic Buttons**
Action	Comment
Control + C	Interrupt signal. This should be your first line of defense.
Control + \	Quit signal. Try this when Control + C doesn't work.
kill -1 -1	UNIX command that kills ALL processes you own. Use when neither of the above work.

Use these “Panic buttons” as necessary - no more no less (they're not a toy). Now that you know how to pull the emergency brake, go ahead and download today's files: (C++ Files) (Worksheet)
Untar the C++ files by using the following UNIX command:
tar zxvf lab13.tar.gz
You may do the worksheet either by hand or using Microsoft Word; it is your choice.

assert()

assert() is a function that takes in one argument: a boolean expression. If the expression is true, execution will continue normally. If it is false, then the program will abort itself and the operating system will print a message saying the assert() failed.

#include <cassert> /* include this for the assert() function */
#include <iostream>
using namespace std;

int main()
{
  double pi;

  cout << "Algebra Quiz: What is pi? ";
  cin >> pi;
  assert(pi == 3.141592);
  cout << "Correct! You know the Archimedes Ratio!" << endl;
  return 0;
}

Note there is no need for an if here because, if the user fails algebra, the program will abort before it congratulates the user on knowing the value of π. You are now ready to do Worksheet Question 1.

g++ Revisited

In lab 00, we learned the compiler command:
g++ -Wall -W -s -pedantic-errors file.cpp -o executable
Remember what the s flag did? It meant “strip”, which strips away all excess information to make the executable as small as possible. But for this debugging lab, we want to add extra debug information to our executable. This raises the question: how will this help if our debug information if “stripped” away? The answer, obviously, is that stripping debug information away is of no help to us and we will therefore eliminate the s flag from our g++ command. This gives rise to another question: if we no longer strip away such debug information, how do we add this debug information in the first place? Well, we just add the ggdb flag (the g flag adds debug information and the gdb subflag adds information the gdb debugger). So, our new compiler command for this lab will be:
g++ -Wall -W -ggdb -pedantic-errors file.cpp -o executable

Now we can compile any file from lab13.tar.gz as above. For instance, to compile assert.cpp, try this command:
g++ -Wall -W -ggdb -pedantic-errors assert.cpp -o assert

gdb Debugger

After compiling the file you're interested in, you can now load it in gdb by typing the command:
gdb executable
gdb will now load and wait for commands at a (gdb) prompt:
(introductory copyright information omitted)

(gdb)

Think of this prompt like any other: a stupid slave waiting for commands from its cruel master. Here is a sketch of gdb commands:

**gdb Commands**
Command	Comment
run	Runs the loaded program
break n	Places a breakpoint at line n (where n is an integer)
break f	Places a breakpoint at the beginning of the function f (where f is a function name)
step	Steps the code one line, proceeding through functions
continue	Continues until the next breakpoint or the program ends/crashes.
backtrace	Traces and displays the function calls that lead us to this point in the code
print x	Print the value of the variable x
quit	Quits gdb

One word on what a breakpoint is: a breakpoint is a place where you are telling the debugger to pause the program's execution so you can run any of the other commands from the table above. You are now ready to do Worksheet Questions 2 - 4.

Extra Credit: ddd

ddd is a graphical front end to gdb. In order to use ddd, you need to be sure of a few things:

You compiled with the ggdb flag as above.
You have an X11 Server running.
PuTTY is configured to use the X11 Server.

(1) is already described.
(2) can be fulfilled in the UMR labs by running XWin-32 (under Start --> Programs --> XWin-32).
(3) is usually set by default on UMR installs. But you can check this by going to Connection --> SSH --> X11. Ensure “Enable X11 Forwarding” is checked and the “X Display Location” is set to localhost:0:
[PuTTY X11 Configuration]

Now you can type the ddd command in the bash-3.00$ prompt and ddd will launch (be patient, it takes a second to load). After it loads, open your executable by selecting File --> Open Program. The screen should now look something like this:
[DDD Main Window]

The front mini-screen is a toolbox giving you fast access to gdb commands. The lower third is a gdb console, which works the same way as the text based gdb we just covered. The middle third is a display of the code in question. The top third is a graph & display area.

The most useful part of ddd is to visualize the data in your program. To do this, select “Display Local Variables” and “Display Arguments” from the Data Menu. You can now proceed with normal gdb commands; ddd will update the displays automatically as you debug.

Appendix: Mathematics Review

The slope between two points (x₁, y₁) and (x₂, y₂) is given by:
$m = \frac{dy}{dx} = \frac{\Delta x}{\Delta y} = \frac{x_2 - x_1}{y_2 - y_1}$
The Fibonacci Sequence is a sequence of numbers defined by:
F_n = F_{n - 1} + F_{n - 2}, where F₁ = F₂ = 1.

Grading & Submission

When you're done, turn in your cs54_lab13.doc file on Blackboard. The worksheet is out of 10 points and has 2 extra credit points available for playing with ddd.

[Dilbert]