Yesterday, My Program Worked. Today, It Does Not. Why?

Imagine some program and a number of changes. If none of these changes is applied (“yesterday”), the program works. If all changes are applied (“today”), the program does not work. Which change is responsible for the failure? We present an efficient algorithm that determines the minimal set of failureinducing changes. Our delta debugging prototype tracked down a single failureinducing change from 178,000 changed GDB lines within a few hours. 1 A True Story The GDB people have done it again. The new release 4.17 of the GNU debugger [6] brings several new features, languages, and platforms, but for some reason, it no longer integrates properly with my graphical front-end DDD [10]: the arguments specified within DDD are not passed to the debugged program. Something has changed within GDB such that it no longer works for me. Something? Between the 4.16 and 4.17 releases, no less than 178,000 lines have changed. How can I isolate the change that caused the failure and make GDB wor...

• Type: Conference
• Year: 1999
• Where: ESEC
• Authors: Andreas Zeller
• Keywords: Delta Debugging, Delta Debugging Prototype, ESEC 1999, GDB Lines, Software Engineering