Chapter 5DebuggingSome errors are easily deduced from a debugger backtrace: Using the wrong variable in an index,etc. Others, particularly when the program’s behavior is unexpected but does not result in a crash, iseasier to debug with application-level debugging output.5.1 A Debugging MindsetDebugging is a process of problem solving. It’s similar to the process that physicians use to diagnoseillness: a combination of experience, reasoning, and tools.Before you start debugging intensively, check the really easy stuff:• make clean—sometimes you may have failed to recompile a particular bit of code. Ithappens more than you’d think.• check compiler warnings—they’re there to let you be lazy. Let them help you. Al-ways use -Wall. Consider also using -Wextra, -Wshadow, -Wunreachable-code.Next, avoid the “it’s not my bug” syndrome. You’ll see bugs that “can’t happen!” (But it did—you have a core dump or error to prove it.) You may be tempted to say “the compiler’s buggy!” (theOS, the course staff, etc.). It’s possible, but it’s very unlikely. The bug is most likely in your code,and it’s even more likely to be in the new code you’ve just added.As a result, some debugging is easy—you can identify it quickly by looking at the output of theprogram, the debugger output (a stack trace is very useful), and take a minute to think about whatcould have caused the problem. Oftentimes, this is sufficient to find the bug, or narrow it down toa very small number of possibilities. This is particularly true in the fairly common case when thebug is in a small amount of recently added code, so look there first. The svn diff commandcan come in very handy for reminding yourself what’s changed! Sometimes you may overlook a“simple” change, or have forgotten something done at 3am the night before.Some very useful steps in debugging, many stolen shamelessly from Kernighan & Pike:• Use a stack trace. The stack trace might tell you exactly where the bug is, if you’re lucky.• Examine the most recent change. Bugs usually show up there.• Read the code carefully. Before you start tweaking, read the code and think about it for a bit.23• Explain your code to someone else. Oftentimes when you read your own code, you’ll readwhat you expect to see, not what’s really there. Explain the code to anyone, even a pet rock.It helps.Harder debugging is often approached as a process of hypothesis elimination:• Make the bug reproducible.• Think about the symptoms (crashing, incorrect result, etc.) of the bug. Look at (or remember)the code involved. Identify the possible and likely causes of these symptoms.• Think about the correct behavior that you expected the program to exhibit, and identify yourreasoning / assumpgions about what state or logic flow in the program would make it actuallydo so.• Identify an experiment that you can perform that will most effectively narrow down the uni-verse of possible causes of the bug and reasons that the program didn’t behave as expected.• Repeat.Experiments you can perform include things like:• Add consistency checks to find out where your assumptions about the program state wentwrong. Is the list really sorted? Did the buffer really contain a full packet?• Add debugging output to show the state of particular bits of the program, or to identify whichparts of the program were being reached (correctly or incorrectly) before the crash.• Remove parts of the code that may be contributing to the bug/crash/etc., to see if they’re reallyresponsible. Note that steps like this are a lot safer if you’ve recently committed your code,perhaps to a development branch.Some of this depends on experience: over time, you’ll have seen more common bugs and canidentify the patterns by which they manifest themselves. But think about it like a binary searchprocess: is the bug caused by one of these causes, or one of those? Can you perform an experimentto cut the field in half?Making the bug easily reproducible is a very important first step. Imagine that your IRC servercrashed when there were 20 clients connected and they’d each sent 1000s of lines of text. Thesituation that caused the bug tells you little about the reason the program failed. Does the bug stillhappen if you have only 10 clients? 5? If they send only 10 lines of code? Simplify the cause asmuch as possible; in its simplest verison, it may directly point out the bug!Writing a log file is a great way to help debug. We’ll talk about this a little more in Section 5.2.Being able to grep through the logfile or analyze it can make the debugging process much easier.Using tools such as electric fence or system call tracers (below) can help identify particular bugsrapidly.Finally, if a bug is really persistent, start writing things down. You’ll save yourself repeatingtests needlessly and will be more likely to cover the space of possibilities.Once you’ve found a bug, think about two things:241. Have I made this bug elsewhere in the code? Bugs that result from misunderstanding inter-faces, etc., are likely to show up in multiple places. Do a quick check to proactively eliminateother bugs.2. How can I avoid making this mistake in the future? You might be able to add test cases toautomatically find them, add assertions to the code to detect if the bug happens again, usecompiler warnings to automatically detect them, or change the way you write the code tomake it impossible to make the mistake.5.2 Good old printf done better: Debug macrosInstead of randomly throwing in and removing printfs while trying to track down bugs, considerusing a bit more structure: debug macros that let you add debugging printfs and not remove them.A good set of debug macros will let you selectively enable and disable different levels of debugverbosity, so that you can immediately go from normal (silent) operation to “full debug” mode justby changing the command line arguments.There are generally two combinable approaches to specifying what debugging information shouldbe output: Some macros provide a tunable “verbosity level” (e.g., 0-9) and other macros allow youto specify which functionality should be debugged (e.g., socket operations, processes, etc.). Morecomplex systems often allow the user to specify verbosity on a per-component or per-functionalitybasis (“verbosity 9 process debugging but verbosity 1 socket debugging”).For purposes of 15-441, we suggest using a relatively
View Full Document
Unlocking...