Philosophy

Debugging is a direct application of the scientific method: developing a theory, testing it, and refining it. The theory may be vague to start with, but you need to have some idea where or when the bug is happening, so that you know what to look for; otherwise, examining the state of the program will be just taking shots in the dark. Debugging is an iterative process; you will frequently find that your ideas about the bug are wrong, and you have to develop new ones. This is normal, and not necessarily unproductive. Sometimes determining what the bug is not helps in determining what it is.

There are two components to efficient debugging:

1. Learning what to look for -- This issue is unfortunately beyond the scope of this discussion, but it does attempt to describe several common problems and their solutions as a means of showing how debug may be used.

2. Learning how to use the available tools -- This topic is about using one tool, a debugger, but there are other tools that are useful in complementary ways. Those tools include lint(1), truss(1), prof(1), and lprof(1) (performance problems and bugs are sometimes related). If you are familiar with all of them you will be more likely to find the right tool for the job. For example, it is faster to find an uninitialized variable with lint than with debug.