Unix Assignment:

Make sure that you have successfully completed the IDEs Asssignment.

Start an xterm on one of the CS Linux servers.

cd to your ~/UnixCourse/idesAsst

The program you are working with is a test driver for a list of names class. The underlying data structure is a linked list, so much of the code involves the manipulation of pointers.

Compile the program and run it. You will see that it behaves properly for part 1 of the test, but then crashes at some later point.

That first test inserts 26 items into the list. Its always a good idea, when debugging, to try and simplify the inputs as much as possible. So its worth trying to reduce the number of inputs as far as we can without changing the erroneous behavior that we are trying to track down.

Its sometimes said that there are really only three numbers in computer programming: zero, one, and more-than-one. This is often used as a reminder during data structure design:

You allocated an array large enough to hold 1000 customer account records? What happens if our busness is successful enough that, a few months from now, we have 1001 customers?

or during algorithm design:

OK, I believe that this loop lists all the delinquent accounts if we have lots of customers who havent paid on time. But what does it do if there is exactly one such customer? Or none?

In our case, we can make a guess that, maybe a bug that crashes the program when we have 26 data items will do so whenever we have more than one. Edit testlist.cpp so that the loop in function main starts off with only 2 data items instead of 26.

Important warning: this is a simple change to a single line of the program. You should not add or remove any lines to the code.

Recompile the program and execute it. Note that the same bug appears.

You may choose to complete this assignment with any of the X-based debuggers covered in this sections lecture notes. Start your debugging session for the testlist program, but do not start executing the program yet.

The program appeared to work just fine on Part 1 of the test. So set a breakpoint at the

cout << ... part 1 ... 

line.

Run the program. Some debuggers will automatically place a breakpoint at the first line of the main() function. If yours stops there, resume execution.

Now you should be at the part 1 breakpoint that you had created. OK, lets check and see if all is right with our list, L.

Use the debugger to view the local variables in this function. Look You should see a variable labeled L, the only local variable in this function.

Use your debugger to examine the variable L. You should see that it contains a data member firstNode. Note that firstNodes data type indicates that it is a pointer (NameListNode*) and its value is non-zero, so we know its pointing to something.

Use your debugger to examine what firstNode points to. Open up the name field until you can see the string it contains (inside the private section). How many steps are required to do this will depend upon which debugger you are using and on whether you set up some of the optional pretty printing features of gdb (discussed in the Lecture Notes). Eventually you should reach a char* pointer that points to something that is obviously a persons name. Write this string down, minus the quotes, for future reference.

The next field in this node is non-zero, and so is apparently pointing to another node. Open it up, and view the string stored inside that node. Note that this nodes next field is null (zero), so we cant go any further. There are only two nodes in this list.

OK, lets move forward a bit through our program. Step inside (not over) the body of clear().

Not much here, is there?

Were in a class member function. The only local variable is the object that we are trying to clear (implicitly named this). Its actually the same object as our earlier list L. It just has a different name inside this function.

Open up this so you can see the name and next fields of the first node.

Step over each of the two staements within the clear function, examining L after each one.

After returning from the clear() call, resume execution. The program will eventually crash.

Just because a program has crashed, you arent necessarily out of luck when running a debugger. You can still obtain a fair amount of information about the location of the crash and the values of the variables at the time of the crash.

Using the debugger, display the call stack (a.k.a. the backtrace) at the time of the crash. Copy down the list of functions (with their code files line numbers) that were active at the time of the crash.

Try examining the values of the variables in the function that was running at the moment of the crash. Can you see the reason for the crash?

Shut down the debugger, and run the command

~cs252/bin/gdbxAsst 

Answer the questions about your debugging session to complete the assignment.