Class 48: Debugging

Held: Friday, 25 April 2003

Summary: Today we consider some fundamental issues related to the process of debugging: Identifying and removing errors from program. */note>

Related Pages:

• EBoard.

Assignments:

• Exam 3: Formal Methods

Notes:

• Start reading the payoff section of Gries. Yes, it will be our focus for all of next week.

Overview:

• Introduction to debugging.
• Offline deubgging.
• Using print statments.
• Using assertions.
• Debuggers

Debugging

• Programs crash.
  • Maybe not Mr. Stone's but everyone else's.
• Why? Subtle and not-so-subtle errors creep in.
• The process of identifying those errors is called debugging.
• There is much controversy over the origin of the term
  • One claim is that it's based on a moth caught in a relay in a very early computer.
  • Others dispute that claim
• Two big debugging questions:
  • It crashed. Where and why?
  • It gave the wrong answer? Why?
• How do you debug?
  • In Scheme?
  • In Java?
  • In other languages you know?
• Debugging is fairly personal; different people find that different techniques work well for them.
• At certain times, debugging seems to invoke a variant of the Heisenberg uncertainty principle
  • Your program behaves fine when debugging is turned on.
  • Your program crashes when debugging is turned off.
• Why might such a situation happen?

Offline Debugging

• A good first approach to debugging is to read through your code (or at least the code of concern) and make sure that the code you've written matches your intent.
• Good things to check: comparison operations, assignment vs. equality testing, termination conditions for loops, ...
• Requires that you understand the intent of the code.
  • But you should.

Debugging via Print Statements

• Many programmers start debugging code by printing status messages at various points of the program.
• With repeated runs, such a technique allows you to binary search the code for where the error occurs.
  • This technique may work particularly well for where did my program crash
• If you incldue not just Got Here messages, but also the state of key variables, you can scan the output to figure out where your program starts doing things incorrectly.
• In some languages, like C, you can do this kind of debugging with minimal overhead:
  • Include a REPORT macro.
  • Set it to a print statement when debugging
  • Set it to null when running normally.
• What are the advantages of this strategy?
• What are the disadvantages?