An Investigation into the Use of Mutation Analysis for Automated Program Repair

Timperley, Christopher Steven; Stepney, Susan; Goues, Claire Le

doi:10.1007/978-3-319-66299-2_7

Cited by 17 publications

(5 citation statements)

References 24 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Further improvements in G&V repair hinge on the capability of improving the precision of fault localization. A promising option is using mutation-based fault localization, which was recently investigated [44] on data from the BugZoo 3 repair benchmarks. [44] found no significant improvement on the overall repair performance-supposedly because the single-edit mutations used in the study may be too simple to reveal substantial differences between programs variants.…”

Section: B Automated Program Repairmentioning

confidence: 99%

Restore: Retrospective Fault Localization Enhancing Automated Program Repair

Chen

Pei

et al. 2022

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

Fault localization is a crucial step of automated program repair, because accurately identifying program locations that are most closely implicated with a fault greatly affects the effectiveness of the patching process. An ideal fault localization technique would provide precise information while requiring moderate computational resources-to best support an efficient search for correct fixes. In contrast, most automated program repair tools use standard fault localization techniques-which are not tightly integrated with the overall program repair process, and hence deliver only subpar efficiency.In this paper, we present retrospective fault localization: a novel fault localization technique geared to the requirements of automated program repair. A key idea of retrospective fault localization is to reuse the outcome of failed patch validation to support mutation-based dynamic analysis-providing accurate fault localization information without incurring onerous computational costs.We implemented retrospective fault localization in a tool called RESTORE-based on the JAID Java program repair system. Experiments involving faults from the DEFECTS4J standard benchmark indicate that retrospective fault localization can boost automated program repair: RESTORE efficiently explores a large fix space, delivering state-of-the-art effectiveness (41 DEFECTS4J bugs correctly fixed, 7 more than any other automated repair tools for Java) while simultaneously boosting performance (speedup over 3 compared to JAID). Retrospective fault localization is applicable to any automated program repair techniques that rely on fault localization and dynamic validation of patches. 1 Fault Closure113 in DEFECTS4J [8] and Tab. III. 1 private void processRequireCall(NodeTraversal t, 2 Node n, Node parent) { 3 ProvidedName provided = providedNames.get(...); 4 ... 5 if (provided != null) { 6 parent.detachFromParent(); 7 compiler.reportCodeChange(); 8 } 9 } Listing 1: Faulty method processRequireCall from class ProcessClosurePrimitives in project Closure Compiler.if (provided != null || requiresLevel.isOn()) { Listing 2: Fix written by tool developers (replacing line 5 in Lst. 1), and also produced by RESTORE.

show abstract

Section: B Automated Program Repairmentioning

confidence: 99%

Restore: Retrospective Fault Localization Enhancing Automated Program Repair

Chen

Pei

et al. 2022

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…Ways to seed faults include mutating the programs using techniques common in mutation testing or seeding a known error into the code. One way to seed a realistic error is to use the edit history of a program's source code to find a change that repaired a bug, then re-introduce the corresponding 'buggy' code into the SUT [33]. Note that obtaining faulty executions by seeding faults does not limit LLANALYZER to only programs for which source code exists because faults can be seeded at any level, including in machine code.…”

Section: Corpus Generationmentioning

confidence: 99%

Using Dynamic Binary Instrumentation to Detect Failures in Robotics Software

Katz¹,

Timperley²,

Goues³

2022

Preprint

View full text Add to dashboard Cite

Autonomous and Robotics Systems (ARSs) are widespread, complex, and increasingly coming into contact with the public. Many of these systems are safety-critical, and it is vital to detect software errors to protect against harm.We propose a family of novel techniques to detect unusual program executions and incorrect program behavior. We model execution behavior by collecting low-level signals at run time and using those signals to build machine learning models. These models can identify previously-unseen executions that are more likely to exhibit errors.We describe a tractable approach for collecting dynamic binary runtime signals on ARSs, allowing the systems to absorb most of the overhead from dynamic instrumentation. The architecture of ARSs is particularly well-adapted to hiding the overhead from instrumentation.We demonstrate the efficacy of these approaches on ARDUPILOT -a popular open-source autopilot software system -and HUSKY -an unmanned ground vehicle -in simulation. We instrument executions to gather data from which we build supervised machine learning models of executions and evaluate the accuracy of these models. We also analyze the amount of training data needed to develop models with various degrees of accuracy, measure the overhead added to executions that use the analysis tool, and analyze which runtime signals are most useful for detecting unusual behavior on the program under test. In addition, we analyze the effects of timing delays on the functional behavior of ARSs.

show abstract

“…The intuition behind these techniques is that when mutants are generated at the faulty location, the test suite should exhibit different behavior than when mutants are generated in non-faulty locations. Further studies [163,198] have suggested that MBFL techniques do not significantly distinguish between faulty and non-faulty locations. Smith et al [187] compare the performance of single patches to N-version patches, where the behavior of the N-version patches is described by a voting system.…”

Section: Software Diversitymentioning

confidence: 99%