LSRepair: Live Search of Fix Ingredients for Automated Program Repair

Liu, Kui; Koyuncu, Anil; Kim, Kisub; Kim, Dongsun; Bissyandé, Tegawendé F.

doi:10.1109/apsec.2018.00085

Cited by 66 publications

(37 citation statements)

References 57 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…With respect to the granularity of fault locality, only LSRepair [41] focuses on the method-level granularity to detect and fix bugs. Other APR systems require information on bugs at the line level to proceed with patch generation.…”

Section: A Integration Of Fl Tools In Apr Pipelinesmentioning

confidence: 99%

You Cannot Fix What You Cannot Find! An Investigation of Fault Localization Bias in Benchmarking Automated Program Repair Systems

Liu

Koyuncu

Bissyandé

et al. 2019

2019 12th IEEE Conference on Software Testing, Validation and Verification (ICST)

Self Cite

124

116

View full text Add to dashboard Cite

Properly benchmarking Automated Program Repair (APR) systems should contribute to the development and adoption of the research outputs by practitioners. To that end, the research community must ensure that it reaches significant milestones by reliably comparing state-of-the-art tools for a better understanding of their strengths and weaknesses. In this work, we identify and investigate a practical bias caused by the fault localization (FL) step in a repair pipeline. We propose to highlight the different fault localization configurations used in the literature, and their impact on APR systems when applied to the Defects4J benchmark. Then, we explore the performance variations that can be achieved by "tweaking" the FL step. Eventually, we expect to create a new momentum for (1) full disclosure of APR experimental procedures with respect to FL, (2) realistic expectations of repairing bugs in Defects4J, as well as (3) reliable performance comparison among the state-of-theart APR systems, and against the baseline performance results of our thoroughly assessed kPAR repair tool. Our main findings include: (a) only a subset of Defects4J bugs can be currently localized by commonly-used FL techniques; (b) current practice of comparing state-of-the-art APR systems (i.e., counting the number of fixed bugs) is potentially misleading due to the bias of FL configurations; and (c) APR authors do not properly qualify their performance achievement with respect to the different tuning parameters implemented in APR systems.

show abstract

Section: A Integration Of Fl Tools In Apr Pipelinesmentioning

confidence: 99%

You Cannot Fix What You Cannot Find! An Investigation of Fault Localization Bias in Benchmarking Automated Program Repair Systems

Liu

Koyuncu

Bissyandé

et al. 2019

2019 12th IEEE Conference on Software Testing, Validation and Verification (ICST)

Self Cite

124

116

View full text Add to dashboard Cite

show abstract

“…The most popular approach to automatically repair bugs is to create a patch using the test suite of the program as the specification of its expected behavior. This type of approach is known as test-suite-based program repair [30], which has been applied in several repair tools in the last decade [2,6,10,13,14,17,18,23,24,27,28,37,42,43,[45][46][47]50].…”

Section: Introductionmentioning

confidence: 99%

Empirical review of Java program repair tools: a large-scale experiment on 2,141 bugs and 23,551 repair attempts

Durieux

Madeiral

Martínez

et al. 2019

Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of

122

124

View full text Add to dashboard Cite

In the past decade, research on test-suite-based automatic program repair has grown significantly. Each year, new approaches and implementations are featured in major software engineering venues. However, most of those approaches are evaluated on a single benchmark of bugs, which are also rarely reproduced by other researchers. In this paper, we present a large-scale experiment using 11 Java test-suite-based repair tools and 5 benchmarks of bugs. Our goal is to have a better understanding of the current state of automatic program repair tools on a large diversity of benchmarks. Our investigation is guided by the hypothesis that the repairability of repair tools might not be generalized across different benchmarks of bugs. We found that the 11 tools 1) are able to generate patches for 21% of the bugs from the 5 benchmarks, and 2) have better performance on Defects4J compared to other benchmarks, by generating patches for 47% of the bugs from Defects4J compared to 10-30% of bugs from the other benchmarks. Our experiment comprises 23,551 repair attempts in total, which we used to find the causes of non-patch generation. These causes are reported in this paper, which can help repair tool designers to improve their techniques and tools.

show abstract

“…[69]. To reduce this threat, a straightforward strategy is to expand the search space, however, which could lead to other two problems: (1) at worst, there still is no correct patch in it; and (2) the expanded search space includes more plausible patches that enlarge the possibility of generating plausible patches before correct ones [34,69].…”

Section: Related Workmentioning

confidence: 99%

TBar: revisiting template-based automated program repair

Liu

Koyuncu

Kim

et al. 2019

Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis

Self Cite

241

155

View full text Add to dashboard Cite

We revisit the performance of template-based APR to build comprehensive knowledge about the effectiveness of fix patterns, and to highlight the importance of complementary steps such as fault localization or donor code retrieval. To that end, we first investigate the literature to collect, summarize and label recurrently-used fix patterns. Based on the investigation, we build TBar, a straightforward APR tool that systematically attempts to apply these fix patterns to program bugs. We thoroughly evaluate TBar on the De-fects4J benchmark. In particular, we assess the actual qualitative and quantitative diversity of fix patterns, as well as their effectiveness in yielding plausible or correct patches. Eventually, we find that, assuming a perfect fault localization, TBar correctly/plausibly fixes 74/101 bugs. Replicating a standard and practical pipeline of APR assessment, we demonstrate that TBar correctly fixes 43 bugs from Defects4J, an unprecedented performance in the literature (including all approaches, i.e., template-based, stochastic mutation-based or synthesis-based APR). CCS CONCEPTS• Software and its engineering → Software verification and validation; Software defect analysis; Software testing and debugging. KEYWORDSAutomated program repair, fix pattern, empirical assessment.

show abstract

LSRepair: Live Search of Fix Ingredients for Automated Program Repair

Cited by 66 publications

References 57 publications

You Cannot Fix What You Cannot Find! An Investigation of Fault Localization Bias in Benchmarking Automated Program Repair Systems

You Cannot Fix What You Cannot Find! An Investigation of Fault Localization Bias in Benchmarking Automated Program Repair Systems

Empirical review of Java program repair tools: a large-scale experiment on 2,141 bugs and 23,551 repair attempts

TBar: revisiting template-based automated program repair

Contact Info

Product

Resources

About