Debugging

What It Is

• Finding and fixing flaws in software
  • Assume for now that you built the right thing the wrong way
  • Requirements errors are actually a major cause of software project failure
• You're going to spend half your professional life debugging
  • After all, once it's fixed, you move on to something else
  • So learn how to do it well
• Talk about tools first (because they'll make everything else less painful)
• Then some simple rules
  • Most taken from [Agans 2002]
• Remember: never debug standing up
  • The faster you try to work, the slower you'll go
• Comment on this slide

What's Wrong with Print Statements

• Many people still debug by adding print statements to their programs
  • “Gee, I wonder what the value of maxTemp is when I call resolve?”
• Debugging with print statements is:
  • Error-prone: adding print statements is a good way to add typos
    • Particularly when you have to modify the block structure of your program to fit it in
  • Time-consuming
    • All that typing…
    • And (if you're using Java, C++, or Fortran) all that recompiling…
  • Misleading
    • Adding print statements moves things around in memory, changes execution timing, etc.
    • Common to have bugs that hide when print statements are added, and reappear when they're removed
• There's a much better way
• Comment on this slide

Symbolic Debuggers

• A symbolic debugger is a program that runs another program on your behalf
  • Called “symbolic” because it can show you the source code you wrote, rather than the raw machine code that's executing
• Using a debugger is one of the two things that separates professionals from amateurs
  • Using version control is the other
• While the target program (or debuggee) is running, the debugger can:
  • Pause, resume, or restart the target
  • Inspect and display the values of variables
  • Change those values
  • Watch for certain events
• Do not need to modify the source of the target program!
  • Depending on your language, you may need to compile it with different flags
  • And yes, the debugger modifies the target's layout in memory, and execution speed…
  • …but a lot less than print statements…
  • …with a lot less effort from you
• Comment on this slide

Running in a Debugger

• Depending on language and tools, there may be several ways to get into the debugger
  • Launch the debugger, load the target program, and start work
  • Run the debugger with the target program as a command-line argument
  • In interpreted languages like Python, you can also switch into debugging mode in the middle of an interactive session
• Sometimes also do post mortem debugging
  • When a program fails badly (e.g., illegal memory access in C++), it creates a core dump
    • Copies all of its internal state to a file on disk
  • Can then load that dump into the debugger, and see where the program was when it died
    • Not as good as watching it run…
    • …but sometimes the best you can do
• Modern graphical debuggers typically show:
  • The source code
  • The call stack
  • The values of variables that are currently in scope
    • I.e., global variables, parameters to the current function call, and local variables in that function
  • A panel displaying what your program has printed to standard output and/or standard error

  • Figure 11.1: A Debugger in Action

• If the debugger is part of a larger integrated development environment (IDE), it may show other things as well
  • A source browser that presents an outline of the project's modules, classes, functions, variables, etc.

  • Figure 11.2: Source Browser

  • A code assistant that presents context-sensitive help and documentation

  • Figure 11.3: Code Assistant

• Note: tools like this are available for every modern language

  • Figure 11.4: Microsoft Visual Studio in Action

• Comment on this slide

Basic Operations

• The debugger can set breakpoints in the target program
  • Tells the target to pause when it reaches particular lines of code
• Once the program is paused, the debugger can single-step it
  • Execute one statement at a time
  • Most can:
    • Step into function calls
    • Step over them, or
    • Run to the end of the current function
• When the target is paused, the debugger can display the contents of its memory
  • The compiler (or interpreter) keeps track of the types of values in memory…
  • …so the debugger can show integers as integers, rather than as sequences of bytes

  • Figure 11.5: Inspecting Values

• Most debuggers can also evaluate expressions using the current values of variables
  • E.g., type in 2*x<0, debugger displays False
  • Yes, this means that every debugger contains a mini-interpreter for the language in question…
• This is a lot easier than adding print statements…
• Comment on this slide

How Debuggers Work

• A running program is:
  • A bunch of bytes in memory whose values are instructions
    • Each statement in the source program typically corresponds to several instructions
    • The compiler (or interpreter) can produce a table that records this mapping
  • Another bunch of bytes whose values are the program's variables
    • The static space contains constant strings, magic numbers, etc.
    • The call stack is the parameters to all currently-active function calls
    • The heap is all dynamically-created objects
  • Some registers
    • An instruction pointer that keeps track of what to execute next
    • A stack pointer to keep track of the call stack
    • Miscellaneous other registers for doing arithmetic, etc.
• In order to set a breakpoint on a particular line, a debugger:
  • Figures out which instructions were produced for the statement on that line
  • Records the first of those instructions in a safe place
  • Replaces that instruction with a HALT instruction
    • Every processor and virtual machine has one of these

  • Figure 11.6: Creating a Breakpoint

• When the target program reaches the HALT instruction:
  • It stops, and sends a signal to the operating system…
  • …which passes the signal on to the debugger…
  • …which waits for instructions from the user
    • Such as “Show me the value of maxTemp”
• When the user wants the program to resume, the debugger:
  • Puts the instruction at the breakpoint location back in place
  • Tells the program to execute just that instruction
    • Every processor and virtual machine has a “single step” mechanism
  • Replaces the instruction with a HALT once again
    • Otherwise, the breakpoint will disappear
  • Tells the program to run normally
• Comment on this slide

Advanced Operations

• Debugger lets you move up and down the call stack
  • Remember, the set of outstanding function calls is just a bunch of variables in memory
  • Debugger can ask how large each one is, so it knows where to go to get to the previous stack frame
  • Lets you figure out how execution got to a particular place
    • Otherwise known as, “What?? We shouldn't be here!!”
• Can modify variables in a running program, too
  • If you have a theory about why an intermittent bug is occurring:
    • Run to that point
    • Set variables' values (e.g., set maxTemp to -1)
    • Resume execution
  • Sometimes used to test error handling code
    • Easier to change timeSpentWaiting to 600 seconds in debugger than to pull out the network cable and wait…
• Can set conditional breakpoints
  • Only pauses program if some condition is met
    • Loop index greater than 100
    • Filename argument to function is None
• Some debuggers also support watchpoints
  • Have the debugger watch every write to memory
  • Halt when anything, anywhere, modifies a particular variable
  • Slow the program down a lot
    • Typically a factor of 100 or more
  • But sometimes the only practical way to find out why a string in C is being overwritten
• Comment on this slide

Rule 0: Get It Right the First Time

• The simplest bugs to fix are the ones that don't exist
• Design, reflect, discuss, then code
  • A week of hard work can sometimes save you an hour of thought
• Make good style a habit
  • Train yourself to do things right, so that you'll code well even when you're tired, stressed, and facing a deadline
• Comment on this slide

Rule 1: What Is It Supposed to Do?

• First step is knowing what the problem is
  • “It doesn't work” isn't good enough
  • What exactly is going wrong?
  • How do you know?
• Requires you to know how the software is supposed to behave
  • Is this case explicit in the specification?
  • If not:
    • Do you have enough knowledge to extrapolate?
    • Do you have the right to do so?
• Write it down!
  • Preferably away from the keyboard and screen
• Try not to let what you're seeing influence what you expect to see
  • Cognitive dissonance leads us to adjust what we think we're observing in order to fit preconceptions
• Question: What do testers do while waiting for code?
  • Answer: read the specification and start writing down test cases
  • If there's no specification, you're wasting valuable time
    • And if QA isn't involved in drawing up the specification, to guarantee testability, you're wasting even more
• Comment on this slide

Rule 2: Is It Plugged In?

• Are you actually exercising the problem that you think you are?
  • Are you giving it the right test data?
  • Is it configured the way you think it is?
  • Is it the version you think it is?
  • Has the feature actually been implemented yet?
• Why are you sure?
  • Maybe the reason you can't isolate the problem is that it's not there
• Another argument in favor of automatic regression tests
  • Guaranteed to rerun the test the same way each time
• Also a good argument against automatic regression tests
  • If the test is wrong, it will generate the same false negative each time
• Comment on this slide

Rule 3: Make It Fail

• You can only debug things when you can see them going wrong
• Find a test case that makes the code fail
  • Then try to simplify it
  • Then try to find another one
  • Use data to weed out false hypotheses
  • Remember, it's computer science, not computer flip-a-coin
• If you can't make it fail repeatedly, you're going to have to rely on:
  • Post-mortem inspection (autopsies)
    • But then you have to reason backwards to figure out why the program crashed
  • Logging with print statements
    • But this can distort the program's behavior
• Comment on this slide

Rule 4: Divide and Conquer

• Once you have a test that makes the system fail, isolate the faulty subsystem
  • Faults can only occur upstream from where the system fails
  • Look at input to the module that's failing
  • If that's wrong, look at preceding module's input, and so on
• Fail early, fail often
  • Use assert to trap consistency errors early
  • Every time you fix a bug, see whether you can add an assertion
    • If you made the mistake once, odds are that you, or someone, will make it again
    • Another strong argument against duplicated code
• Comment on this slide

Rule 5: Change One Thing at a Time, For a Reason

• Replacing random chunks of code unlikely to do much good
  • If you got it wrong the first time, what makes you think you'll get it right the second? Or the ninth?
  • So always have a hypothesis before making a change
• Change one thing, then re-run your tests
  • Changes can often uncover (or introduce) new bugs
  • The more things you change at once, the harder it is to know what's responsible for what
  • And the harder it is to keep track of what you've done, and what effect it had
• Comment on this slide

Rule 6: Write It Down

• Science works because scientists keep records
• If you try to keep the state of play in your head, you will lose track (and time)
  • “Wait, didn't A followed by B with an odd number of lines cause those symptoms? Or was it B followed by A? Or was it A and B with an even number of lines?”
• Records particularly useful when getting help
  • People are more likely to listen when you can explain clearly what you did
• Comment on this slide

Rule 7: Be Humble

• If you can't find it in 15 minutes, ask for help
  • Just explaining the problem aloud is often enough
• Don't keep telling yourself why it should work: if it doesn't, it doesn't
  • Never debug while grinding your teeth, either…
• Keep track of your mistakes
  • Just as runners keep track of their time for the 100 meter sprint
  • You're most likely to fix what you're paying attention to
• Comment on this slide

Summary

• How productive you are depends on:
  • What tools you use
  • How well you use them
• A symbolic debugger will make you more productive
  • Like any other tool, there's a learning curve
  • But after a few sessions, you will have more working code in less time
• The best debugger in the world is no substitute for working methodically
  • The scientific method is the best tool we've ever invented for finding out “why”
• Comment on this slide