Dynamic slicing and its underlying dynamic dependence analysis have been extensively studied and used as the foundation for numerous automated-debugging techniques. One limitation of dynamic slicing, when used for debugging, is that it only considers program dependences that are actually observed during the execution(s) of interest. Some faults, however, involve potential, rather than actual dependences-dependences that would be observed if the correct program was executed but are missing when the faulty program is executed. In particular, traditional dynamic slicing may fail to locate faults that involve assignments that should have occurred in a correct execution and did not occur in the failing execution being debugged. Relevant slicing techniques partially address this problem by identifying missing assignments due to incorrect control-flow. However, they do not consider the case of assignments that do occur but modify the wrong memory location (e.g., the wrong element of an array). Debugging techniques based on existing dynamic slicing approaches may therefore miss faults in the presence of this kind of incorrect assignments. To address this problem, we introduce the concept of potential memory-address dependence (PMD). Intuitively, PMDs represent the dependence relationship between an instruction s that affects the computation of a memory-address ma (e.g., by defining an array index or a pointer offset) and memory read instructions that are not observed to be dependent on s but could be affected by s (i.e., access the memory at ma) in a counterfactual execution of s. We also present a technique that computes PMDs and represents them on standard dynamic dependence graphs. To assess the effectiveness of our technique for debugging, we implemented PMD-Slicer, a dynamic slicer that accounts for PMDs, and performed an empirical evaluation on a benchmark of 364 real faults and 880 fault-revealing test cases. Our results are promising, in that almost 10% of the failing tests contained cases in which PMD-Slicer generated slices that included the corresponding fault, while a traditional dynamic slicer did not. Furthermore, considering PMDs only moderately increased slice sizes.

Repairing broken tests in evolving software systems is an expensive and challenging task. One of the main challenges for test repair, in particular, is preserving the intent of the original tests in the repaired ones. To address this challenge, we propose a technique for test repair that models and considers the intent of a test when repairing it. Our technique first uses a search-based approach to generate repair candidates for the broken test. It then computes, for each candidate, its likelihood of preserving the original test intent. To do so, the technique characterizes such intent using the path conditions generated during a dynamic symbolic execution of the tests. Finally, the technique reports the best candidates to the developer as repair recommendations. We implemented and evaluated our technique on a benchmark of 91 broken tests in 4 open-source programs. Our results are promising, in that the technique was able to generate intentpreserving repair candidates for over 79% of those broken tests and rank the intent-preserving candidates as the first choice of repair recommendations for almost 70% of the broken tests.

Numerous automated techniques have been proposed to reduce the cost of software debugging, a notoriously time-consuming and human-intensive activity. Among these techniques, Statistical Fault Localization (SFL) is particularly popular. One issue with SFL is that it is based on strong, often unrealistic assumptions on how developers behave when debugging. To address this problem, we propose Enlighten, an interactive, feedback-driven fault localization technique. Given a failing test, Enlighten (1) leverages SFL and dynamic dependence analysis to identify suspicious method invocations and corresponding data values, (2) presents the developer with a query about the most suspicious invocation expressed in terms of inputs and outputs, (3) encodes the developer feedback on the correctness of individual data values as extra program specifications, and (4) repeats these steps until the fault is found. We evaluated Enlighten in two ways. First, we applied Enlighten to 1,807 real and seeded faults in 3 open source programs using an automated oracle as a simulated user; for over 96% of these faults, Enlighten required less than 10 interactions with the simulated user to localize the fault, and a sensitivity analysis showed that the results were robust to erroneous responses. Second, we performed an actual user study on 4 faults with 24 participants and found that participants who used Enlighten performed significantly better than those not using our tool, in terms of both number of faults localized and time needed to localize the faults.