Search |  Contact |  SRI Home Do not follow this link, or your host will be blocked from this site. This is a spider trap. Do not follow this link, or your host will be blocked from this site. This is a spider trap. Do not follow this link, or your host will be blocked from this site. This is a spider trap.A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A ASRI International.  333 Ravenswood Avenue.  Menlo Park, CA 94025-3493. SRI International is a nonprofit corporation.

AIC Seminar Series

Debugging Reinvented: Asking and Answering Why and Why Not Questions about Program Behavior

Andy KoCarnegie Mellon University[Home Page]

Notice:  hosted by Vinay Chaudhri

Date:  2008-01-31 at 16:00

Location:  EJ228 (SRI E building)  (Directions)

   Abstract

Most software undergoes a brief period of rapid development, followed by a much longer period of maintenance and adaptation. As a result, software developers spend most of their time exploring a system’s underlying source code to determine the parts of the system that are relevant to their tasks. Because these parts are often distributed throughout a system’s modules, and because they can interact in complex and unpredictable ways, this process of understanding a program’s execution can be extremely difficult. The primary cause of this difficulty is that developers must answer their questions about a system’s behavior by guessing. For example, a developer wondering, "Why didn’t this button do anything after I pressed it?" must form an answer such as "Maybe because its event handler wasn’t called" and then use breakpoint debuggers, print statements, and other low-level tools to verify the explanation. Not only is this process poorly supported by current tools, but worse yet, there are many potential explanations for a system’s behavior, so developers rarely formulate a valid explanation on the first attempt. To address this problem, I present a new kind of program understanding tool called a Whyline, which allows a developer to select "why did" and "why didn’t" questions directly about the symptoms of a system’s behavior. In response, the Whyline determines which parts of the system and its execution are related to the symptom in question, while also identifying false assumptions the developer might have about what occurred during the execution of the program. By using this approach, developers need not guess about potential causes of program behavior: they simply point to some perceptible feature of the faulty behavior and the system identifies the relevant code. Early prototypes of the Whyline for a simplified educational programming language reduced debugging time by a factor of 8. I have since generalized the Whyline to support Java programs with textual and graphical output, inventing several new incremental algorithms to identify program-specific output, derive output-relevant questions, and answer questions about a variety of output. A preliminary study of the Java Whyline found that even people with no program experience using the Whyline could isolate a bug 3 times faster than experts with conventional debugging tools.

   On-line Resources