Scholarly Resources for CompSci Undergrads

C Programming Language

Notes about C Debugging

Lecture Notes: HTML/Javascript version


The rest of this webpage is organized into the following sections:


This lecture was originally written for Turbo Pascal, then updated for the first ANSI C standard, then object-free C++. It does not address anything specific about object-oriented or real-time programming. I am confident that the general advice will apply well to those types of programming too.

When you wrote your program you thought it would work, but now you've found that it doesn't. `What's wrong? How can you fix it?' That's debugging. Debugging is not the same as fixing syntax errors that prevent compilation.

`The term originated with the first tube computers': Talk about Grace Hopper and the moth (from 1947).
[photo of moth in logbook]

To Solve a Problem You Must Understand It

Tracing the execution will help you to understand what is happening with your program. If you know which part is wrong then you can trace just that part.


We call the written form of our program `code', as in difficult-to-understand. It must be written in a language that the computer can process but that does not mean that is has to be written so that we cannot understand it too. It is hard enough to read code when we think we know what we are instructing the computer to do. But especially when we know that the program doesn't work right then we need to have clear code and clear output.

Always print to standard error

Your output will appear `immediately' -- it won't get muddled up with some other output. If you use cout for debugging then you can be misled easily.

Always print the function name


  1. story about Bill
  2. annotated example
DEBUG levels

Use larger numbers for more detail or for parts you think work now (but you don't want to remove the DEBUG code just in case you're wrong).


Debuggers can be mesmerizing. I've seen it happen.

Programs will sometimes behave differently in a debugger than in real-life.

There's never time...

It sounds trite but it is true.

Programmers will jump into writing a program or trying to fix a broken one without thinking. You can save yourself much fruitless labour and frustration by planning ahead. The better your plan the less likely your program will be to fail and the more likely you'll be to fix it if it does fail.

Trace Statements

A true-life story

My friend Bill didn't do this and spent one-and-a-half days debugging the wrong part of his program. He was printing `Hi' or something to show when the flow-of-control had reached a statement. The problem was that he had two `Hi's in different parts of the program. He was seeing the second one -- the first was never reached.

I found the problem in one minute by changing `Hi' to something more descriptive (`inner for loop' or something). Bill had to buy me lunch and I didn't even know the language he was programming in.

If that technique can help a professional programmer save one-and-a-half days, think how the power of debugging can help you.

An ounce of analysis...

Another true-life tale

I was in a computer lab working on a brutal assignment (a recursive BNF parser in Modula 2 -- don't ask, trust me it's not super easy) and the grader comes in every 2 or 3 hours to say that he's changing the assignment (again!). Never mind that is beyond his authority. Suffice it to say that I was stressed and could not get my program to work right.

By the way I was sitting beside a fellow who was also in the class. I'll call him Stu Dent (not his real name). Stu was a rower and had practice at 6 the next morning.

Anyway, for some reason I noticed that the program was not due the next day but rather the day after that. It was late and I was tired. I printed a copy of my program took it with me and left. I slept.

In the morning, I scribbled an outline of a correct program on a piece of paper, while I waited for my cereal to stop making noise. Then, on my printout I crossed off the lines that did not belong and added the ones that were missing. When I got back to school, Stu was at the same terminal -- he'd been there all night, and still didn't have a working program. I typed in my changes and it was perfect. Stu finished his a day later -- a 10% penalty -- and missed rowing practice.

What's the moral of this true story? Not sleep whenever you have a problem but:

Annotated example

JavaScript testing

I have tested the Javascript version with Netscape Communicator (versions 4.7, 4.76, & 4.78), Opera (version 5.0), Mozilla version, Lynx (version 2.7.1ac-0.74) and Internet Explorer (versions 5.00... and 5.50...).

had trouble when the secondary window closed
couldn't seem to tell that the secondary window closed
NS 4.7 (for M$DOS)
seemed to ignore the <noscript> tag
But otherwise
they all worked fine.

If you've had any trouble with the Javascript version then you might prefer the PostScript® or PDF® versions.

Last updated by J. Blustein on 28 April 2002.

This document is copyright by its author, J. Blustein <>.

HTML validation check