Debugging Techniques

If debugging is the process of removing bugs,
then programming must be the process of putting them in...

We've talked about a little already about how to use printf() statements to debug your programs, and by now all of you realize that it usually takes more time to debug a program than it does to write it.

The good news is, as you gain more experience you'll make fewer logic and syntax errors. You'll also get better at debugging your own code.

The bad news is, it's going to take a lot of experience.

Today we're going to discuss some basic debugging techniques, including the use of a symbolic debugger to help you find and fix errors in your code.

Basic steps to debugging

• Recognize that a bug exists
• Isolate the source of the bug
• Identify the cause of the bug
• Determine a fix for the bug
• Apply the fix and test it

Compile time vs. runtime

• As you know there are several stages to debugging your program: getting it to compile, getting it to link, getting it to run, and getting it to run correctly.
• In debugging, the issue is catching "compile time" vs. "runtime" errors.

Compile time errors

The compiler identifies several kinds of errors:

• Syntactic errors
• Type mismatches
• Warnings about deprecated features
• Warnings about implicit declarations

Linker errors

Linker errors tend to be simple and are usually caused be forgetting to include an object file or failing to define a function in one of them.

% gcc proj3.o wator.o 
proj3.o: In function `main':
proj3.o(.text+0x121): undefined reference to `PopulateOcean'
wator.o: In function `GetNewPosition':
wator.o(.text+0x65a): undefined reference to `GetRandomNumber'
collect2: ld returned 1 exit status
% 

Runtime errors

• Some runtime errors result in complete failure and little or no information is available, e.g., infinite loops, segmentation faults, crashing the operating system, etc.
• Other runtime errors just produce results that are not correct.