iFixR: bug report driven program repair

Koyuncu, Anil; Liu, Kui; Bissyandé, Tegawendé F.; Kim, Dong–Sun; Monperrus, Martin; Klein, Jacques; Traon, Yves Le

doi:10.1145/3338906.3338935

Cited by 68 publications

(37 citation statements)

References 102 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…• Test-suite availability: The bug benchmarks must include test cases [55] (or bug fixes that can be used for easily writing relevant test cases [21]) for each API-related bug. Namely, for each API misuse, we should have at least one failing test case.…”

Section: Selectionmentioning

confidence: 99%

“…uk/os/apiarty.html. [13] Generic REPAIRTHEMALL ARJA-GENPROG [7] Generic REPAIRTHEMALL ARJA-KALIA [14] Functionality removal REPAIRTHEMALL ARJA-RSREPAIR [15] Statement change REPAIRTHEMALL ASTOR-CARDUMEN [16] Statement change REPAIRTHEMALL ASTOR-GENPROG [17] Generic REPAIRTHEMALL ASTOR-KALI [18] Functionality removal REPAIRTHEMALL ASTOR-MUTREPAIR [18] Generic REPAIRTHEMALL AVATAR [19] Static violations DEFECTS4J CAPGEN [20] Generic DEFECTS4J IFIXR [21] Template-based DEFECTS4J SIMFIX [22] Similarity-based DEFECTS4J SKETCHFIX [23] Generic DEFECTS4J TBAR [24] Template-based DEFECTS4J…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Evaluating Automatic Program Repair Capabilities to Repair API Misuses

Kechagia

Mechtaev

Sarro

et al. 2022

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

API misuses are well-known causes of software crashes and security vulnerabilities. However, their detection and repair is challenging given that the correct usages of (third-party) APIs might be obscure to the developers of client programs. This paper presents the first empirical study to assess the ability of existing automated bug repair tools to repair API misuses, which is a class of bugs previously unexplored. Our study examines and compares 14 Java test-suite-based repair tools (11 proposed before 2018, and three afterwards) on a manually curated benchmark (APIREPBENCH) consisting of 101 API misuses. We develop an extensible execution framework (APIARTY) to automatically execute multiple repair tools. Our results show that the repair tools are able to generate patches for 28% of the API misuses considered. While the 11 less recent tools are generally fast (the median execution time of the repair attempts is 3.87 minutes and the mean execution time is 30.79 minutes), the three most recent are less efficient (i.e., 98% slower) than their predecessors. The tools generate patches for API misuses that mostly belong to the categories of missing null check, missing value, missing exception, and missing call. Most of the patches generated by all tools are plausible (65%), but only few of these patches are semantically correct to human patches (25%). Our findings suggest that the design of future repair tools should support the localisation of complex bugs, including different categories of API misuses, handling of timeout issues, and ability to configure large software projects. Both APIREPBENCH and APIARTY have been made publicly available for other researchers to evaluate the capabilities of repair tools on detecting and fixing API misuses.

show abstract

Section: Selectionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Evaluating Automatic Program Repair Capabilities to Repair API Misuses

Kechagia

Mechtaev

Sarro

et al. 2022

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…We successfully generatred 17 fine-grained fix templates, which were evaluated to be effective in patching 17 out of 20 real-world crashed apps. CraftDroid can benefit the automatic program repair (APR) community [18,20,[29][30][31][32][33][34][35] in establishing a new means to augment datasets. CraftDroid can also benefit the developer community in recommending effective patches to fix their crashed apps.…”

Section: Discussionmentioning

confidence: 99%

Mining Android crash fixes in the absence of issue- and change-tracking systems

Kong

Gao

et al. 2019

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

Self Cite

View full text Add to dashboard Cite

Android apps are prone to crash. This often arises from the misuse of Android framework APIs, making it harder to debug since official Android documentation does not discuss thoroughly potential exceptions.Recently, the program repair community has also started to investigate the possibility to fix crashes automatically. Current results, however, apply to limited example cases. In both scenarios of repair, the main issue is the need for more example data to drive the fix processes due to the high cost in time and effort needed to collect and identify fix examples. We propose in this work a scalable approach, CraftDroid, to mine crash fixes by leveraging a set of 28 thousand carefully reconstructed app lineages from app markets, without the need for the app source code or issue reports. We developed a replicative testing approach that locates fixes among app versions which output different runtime logs with the exact same test inputs. Overall, we have mined 104 relevant crash fixes, further abstracted 17 fine-grained fix templates that are demonstrated to be effective for patching crashed apks. Finally, we release ReCBench, a benchmark consisting of 200 crashed apks and the crash replication scripts, which the community can explore for evaluating generated crash-inducing bug patches. CCS CONCEPTS • Software and its engineering → Software testing and debugging; Software libraries and repositories.

show abstract

“…In this study, we summarize the curation of test suites into three categories: (1) to include the bug-triggering test cases which are often added after a user-reported bug is fixed by a developer, (2) to rewrite previous test cases to focus on the spotted buggy lines, and (3) to insert assertions in program source code in order to ensure that test cases properly reveal the bugs. Eventually, Defects4J is a clean research dataset which may not represent the types of buggy programs APR tools will be applied on in real-world development settings (Koyuncu et al, 2019). Table 12 provides details on the number of benchmark bugs in Defects4J (Just et al, 2014), Bugs.jar (Saha et al, 2018) and Bears (Madeiral et al, 2019) that are associated with bug-triggering test cases that have been added/updated after the bug is reported.…”

Section: Rq4: Apr Benchmark Biasesmentioning

confidence: 99%

A critical review on the evaluation of automated program repair systems

Kui

Koyuncu

et al. 2021

Journal of Systems and Software

Self Cite

View full text Add to dashboard Cite

Automated Program Repair (APR) has attracted significant attention from software engineering research and practice communities in the last decade. Several teams have recorded promising performance in fixing real bugs and there is a race in the literature to fix as many bugs as possible from established benchmarks. Gradually, repair performance of APR tools in the literature has gone from being evaluated with a metric on the number of generated plausible patches to the number of correct patches. This evolution is necessary after a study highlighting the overfitting issue in test suite-based automatic patch generation. Simultaneously, some researchers are also insisting on providing time cost in the repair scenario as a metric for comparing state-of-the-art systems. In this paper, we discuss how the latest evaluation metrics of APR systems could be biased. Since design decisions (both in approach and evaluation setup) are not always fully disclosed, the impact on repair performance is unknown and computed metrics are often misleading. To reduce notable biases of design decisions in program repair approaches, we conduct a critical review on the evaluation of patch generation systems and propose eight evaluation metrics for fairly assessing the performance of APR tools. Eventually, we show with experimental data on 11 baseline program repair systems that the proposed metrics allow to highlight some caveats in the literature. We expect wide adoption of these metrics in the community to contribute to boosting the development of practical, and reliably performable program repair tools.

show abstract

iFixR: bug report driven program repair

Cited by 68 publications

References 102 publications

Evaluating Automatic Program Repair Capabilities to Repair API Misuses

Evaluating Automatic Program Repair Capabilities to Repair API Misuses

Mining Android crash fixes in the absence of issue- and change-tracking systems

A critical review on the evaluation of automated program repair systems

Contact Info

Product

Resources

About