Cs102 Spring 2005 Lab3

Due Date: Wednesday Oct 26 at midnight


In this lab you will learn to use the ddd debugger on eagle. It is one of the original graphical debuggers. You may be familiar with some of the newer graphical debugging tools such as the one that comes with MS visual studio or Borlands compiler suite. DDD works on the same principle.

Read the entire lab before starting work on it, I think you will find the lab easier to do if you have read the entire assignment.


In this lab you will:

Your task:

You have been recently hired at a company, and to get you used to their software, they asked you to debug a program for them. A recently dismissed programmer wrote it and told his supervisor "Its all set - it compiles, but I've not tested it yet."  After the subervisor compiled the program and tried to run it, the supervisor found that the program immediately crashed. You need to find the bugs in the program so that it meets the requirements

The Requirements:

When you have debugged the program, it should look something like the following:
finished lab 3
Your borders may be different, but the contents of the window should look like the above image.

The behavior of the application should be as follows:

Its pretty simple behavior, but your predicessor didn't debug the program and there are several common bugs in the program that you will need to find and fix.

Getting Started

First we need to use a newer compiler. If you haven't recopied my initialization file to get the now one, follow the instructions in lab1 and do so.

Remember to logout and log back in to get the effects.

Now copy the files to begin this lab.

cp ~jsantore/lab3Start.zip .

unzip the file

unzip lab3Start.zip

this makes a lab3 directory in your home directory. Change into that directory and look at the files

cd lab3

you have three cpp files, three header files, a Makefile and a copy of the image of the running program. Compile the files:

make Lab3

and great! it compiles just fine. You now have an executable program called lab3 in your directory. Try running the program


oops it crashed. So now you need to use the debugger to find the errors. Lets look at the first one together:

First you need to run the debugger on the program. The name of the debugger is ddd, so run

ddd lab3 &

All the '&' character does is tell the program to run in the 'background' so that you get your prompt back to type another command.

When ddd is finished starting up, you can see the code for the app class displayed in the window. To open another file for later debugging, choose <file><open source> You will only need to look at App.cpp, Frame.cpp and Calculate.cpp. The other files listed below those are part of the library and they are not part of the problem.

First we are going to set a 'breakpoint'

A breakpoint is a place that the debugger will stop the execution of the program so that you can view the value of variables and view the exection of your program in slow motion.

Lets set a breakpoint at the beginning of the Lab3App::OnInit() method. (Note that the wxWindows library does not follow our class naming conventions, so there are places where this code deviates from that naming convention unfortunately)

To set a breakpoint, put your mouse over the leftmost part of the line of code, right next to the edge of the window. Right click on that blank space and a menu with four menu items will appear. (if you get a larger menu, your mouse isn't over the blank space) The first menu item is <set breakpoint>, Bring this menu up just left of the word bool that denotes the return type of the Lab3::OnInit() method. Select the <set Breakpoint> item and a red "stop" sign will  appear over  part of the line. Now tell ddd to run the program (either select <program><run> or push the green <run> button on the little button bar that ddd pops up.

A message appears in the bottom pane of ddd telling you that a breakpoint was encountered.  And you will see a green arrow next to the red stop sign.

In a moment we will continue execution of the program, but for now lets watch the value of the variable mainFrame. One nice way to do this is to display its value using ddd. right click on the first place that you see mainFrame. You will get a menu with 8 choices. The second one is <display mainFrame>  choose that item.

The variable mainFrame is now displayed - note that is currently has some garbage value since it is uninitialized.

Now we are going to step through the program in slow motion to try to figure out what is going wrong (Generally we do not want to step through the entire program, rather, you want to find the method that you think is causing you trouble and then step through it.)

To step, we will use the step option in ddd (either <program><step> or push the step button on the ddd button bar. Use the step option three time. Watch the value of mainFrame change in the display pane as you step. Note that after the third step, the green arrow has turned red and has a lightning bolt through it. This means that the program has crashed.

We can now see the reason that the program was crashing. Look at the displayed value of mainFrame: it is 0x0 otherwise known as NULL. So the program is trying to call the Show method on a NULL pointer - something that certianly won't work.

Looking a little closer at the OnInit method we see that your predecessor commented out the constructor call that initializes mainFrame for some reason. Quit ddd. Uncomment that line and recompile the program.

Now try to run it. and Hey! you have a window!

of course there are still several more bugs to find and fix, but that is what this lab is all about.

There are either 5 or 6 (depending on how you count) more bugs to find.

None of the bugs will require you to call any method of any wxWindows class in order to fix the bug.

All of the bugs are in the three files:


Good luck in finding them. Enjoy.

The wxWindow Library

This program uses several classes from the wxWindow library. It is not necessary to understand all or even most of the classes that are provided in the wxWindow library. However if you want more documentation than is available here you can find the class list and API on the web and you might find it helpful.

Below is a list of the wxWindows classes used in this lab and a description of those methods that are used in this lab.

What to hand in

    As usual, you need to submit a zip file with all of your work. (you may omit the object files to save some time and space if you wish.
    In addition to the code, you need your readme file which should have slightly different sections this time
  1. Your name
  2. The names of the files that you are submitting.
  3. What bugs you found and what changes you made to fix those bugs and why you think this is the right solution.
  4. And remaining bugs that you were not able to solve.
The readme will be worth a good piece of the grade this time.