Locating faults through automated predicate switching

Abstract

Typically debugging begins when during a program execution a point is reached at which an obviously incorrect value is observed. A general and powerful approach to automated debugging can be based upon identifying modifications to the program state that will bring the execution to a successful conclusion. However, searching for arbitrary changes to the program state is difficult due to the extremely large search space. In this paper we demonstrate that by forcibly switching a predicate's outcome at runtime and altering the control flow, the program state can not only be inexpensively modified, but in addition it is often possible to bring the program execution to a successful completion (i.e., program produces the desired output). By examining the switched predicate, also called the critical predicate, the cause of the bug can then be identified. Since the outcome of a branch can only be either true or false, the number of modified states resulting by predicate switching is far less than those possible through arbitrary state changes. Thus, it is possible to automatically search through modified states to find one that leads to the correct output. We have developed an implementation based upon dynamic instrumentation to perform this search through program re-execution -the program is executed from the beginning and a predicate's outcome is switched to produce the desired change in control flow. To evaluate our approach, we tried our technique on several reported bugs for a number of UNIX utility programs. Our technique was found to be practical (i.e., acceptable in time taken) and effective (i.e., we were able to automatically identify critical predicates). Moreover we show that bidirectional dynamic slices of critical predicates capture the faulty code.

Contract-based program repair without the contracts

“…Nopol [36] only targets conditional expressions, and uses a form of angelic debugging [3], [37] to reconstruct the expected value of a condition in passing vs. failing runs; based on it, it synthesizes a new conditional expression using an SMT solver. SPR [16] also combines condition synthesis with a dynamic analysis of the value each abstract conditional expression should take to make all tests pass, which helps aggressively prune the search space when no plausible repair exists.…”

Interactive Fault Localization Using Test Information

“…Besides the preceding approaches, Zhang et al [18] explored the effectiveness of three dynamic slicing techniques (data slicing, full slicing and relevant slicing) on fault localization. Their later work [19] proposed the concept of critical predicates, and uses critical predicates with other slicing techniques to locate faults. Different from these automated approaches, our approaches are interactive, which combine the test information and feedback information from the developer in the fault-localization process.…”

RUGRAT: Runtime Test Case Generation Using Dynamic Compilers

“…Dynamic compilers are commonly used to speed up interpreted code (e.g., all JVMs are dynamic compilers) and used for on-the-fly program optimizations [2]. Dynamic compilers also have been used to ensure a program does not allow unauthorized control transfers [14], to locate faults by dynamically switching predicates [27], and to perform coverage analysis [18] and impact analysis [4].…”

“…Note that RUGRAT offers more accuracy and benefits than simply changing branch predicates [27] to execute the error handling code. RUGRAT selectively fails a particular call by changing the return value and, possibly, modifying other variables as side effects of the function.…”