Lab - Debugging

Okay, just follow along, questions will be denoted with a Q.

See a short (and still incomplete) GDB quick reference

Setup

Q 1What happened when you ran bug3? Use ls -ot, see if there are any new files in your directory.

Loading corefile into GDB

Even if you didn't compile w/the extra debug info, and you don't read the instructions for the given chipset, the debugger can still be useful. For example, we can use backtrace (bt) to look at the runtime stack, see in which function we were when we dumped:

Q 2 In which function did it bomb?

Setup

To run programs in a debugger (and see stuff that looks familiar to you) you must compile all files w/the -g flag.

Running programs inside GDB

Okay, now, use GDB to debug these other programs.

Q 3 For each, below, record what the problem was, and how you fixed it.

  1. bug1.c - common bug in C.
  2. bug2.c - common bug in C.
  3. bug3.c - when tested with in.bug3 as input
  4. avg.c - example use of assert.
  5. A program that causes a segmentation violation:

    driverBug.c compiled with quicksortBug.c.

    simple bug in the quicksort program from the text - how would you find it? What assertions could you put into the code to check that the algorithm was implemented properly?

    To generate the error run driverBug with the input in

sort2.c uses qsort to sort an array of strings. The error comes from passing qsort a function to compare integers rather than strings.

Q 4 Why can't the compiler catch this? You can uncover the problem by looking at a stack trace from when the program crashed (see the lab on how to do this).

Q 5 What happens if you are using qsort to sort integers and accidently pass the string comparison function?