Improving performance of automatic program repair using learned heuristics

Schramm, Liam

doi:10.1145/3106237.3121281

Cited by 5 publications

(2 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Prophet [33] ranked and validated generated patches by the similarities with human written patches according to extracted program value features and modification features. Schramm et al [34] combined the speed of Prophet's feature-based search and the reliability of SearchRepair's constraint solving. After compared several machine-learning methods to identify better patch candidates, it used random forest to finally obtain 96% accuracy.…”

Section: Pattern-based Tbrmentioning

confidence: 99%

A Survey of Test Based Automatic Program Repair

Liu¹,

Long²,

Zhang³

2018

JSW

View full text Add to dashboard Cite

Abstract:Testing and debugging have always been the most time-consuming parts of the software development procedure and require large amounts of human resources. When a bug is located, manually fixing it to repair the buggy program is still a difficult and laborious task for developers. Hence automatic program repair techniques, especially the test-based approaches, have drawn great attentions in recent years. Researchers have explored and proposed various novel methods and tools, pushing the idea closer to reality. In this paper, we systematically survey the work in mainstream of test-based program repair (TBR) and discuss the properties automatically generated patches should have. We classify the state-of-the-art approaches for TBR, and evaluate their strengths and weaknesses according to their functional mechanisms. Finally, we refer to some empirical results and propose four important issues, which are supposed to be critical and constructive in this research area.

show abstract

Section: Pattern-based Tbrmentioning

confidence: 99%

A Survey of Test Based Automatic Program Repair

Liu¹,

Long²,

Zhang³

2018

JSW

View full text Add to dashboard Cite

show abstract

“…For example, Facebook proposed SapFix [44] that runs as part of their continuous integration infrastructure and can suggest bug fixes for runtime crashes; Google proposed DeepDelta [46], which automatically learns to suggest fixes for build-time compilation failures. The main advantage of a learning-based approach over more traditional techniques such as constraint-based [42,62,76], heuristicbased [63], search-based [31,37,45], or dynamic [38] and static [16] analysis-based repair, is that it does not require domain-specific knowledge about bug patterns and fixes in a given programming language.…”

Section: Introductionmentioning

confidence: 99%

A Controlled Experiment of Different Code Representations for Learning-Based Bug Repair

Namavar¹,

Nashid²,

Mesbah³

2021

Preprint

View full text Add to dashboard Cite

Training a deep learning model on source code has gained significant traction recently. Since such models reason about vectors of numbers, source code needs to be converted to a code representation and then will be transformed into vectors. Numerous approaches have been proposed to represent source code, from sequences of tokens to abstract syntax trees. However, there is no systematic study to understand the effect of code representation on learning performance. Through a controlled experiment, we examine the impact of various code representations on model accuracy and usefulness in learning-based program repair. We train 21 different models, including 14 different homogeneous code representations, four mixed representations for the buggy and fixed code, and three different embeddings. We also conduct a user study to qualitatively evaluate the usefulness of inferred fixes in different code representations. Our results highlight the importance of code representation and its impact on learning and usefulness. Our findings indicate that (1) while code abstractions help the learning process, they can adversely impact the usefulness of inferred fixes from a developer's point of view; this emphasizes the need to look at the patches generated from the practitioner's perspective, which is often neglected in the literature, (2) mixed representations can outperform homogeneous code representations, (3) bug type can affect the effectiveness of different code representations; although current techniques use a single code representation for all bug types, there is no single best code representation applicable to all bug types. Table 1: Different code representations for the example of Listing 1 Representation ID (RID) Category Representation Example WT1 non-AST based Word tokenization [20, 21, 24] setTimeout ( delay , fn ) WT2 Enhanced word tokenization [27, 41] set Timeout ( delay , fn ) DB1 DeepBugs [58] ID setTimeout ( ID delay , ID fn ) DB2 DeepBugs with types and variable values ID setTimeout ( ID number delay , ID function fn ) DB3 DeepBugs with types without variable values ID setTimeout ( ID number , ID function ) FS1 Function signature setTimeout ( number , function ) FS2 Function signature with position anchors setTimeout ( arg0 number , arg1 function ) FS3 Function signature with LIT/ID setTimeout ( ID number , ID function ) FS4 Function signature with position anchors and LIT/ID setTimeout ( arg0 ID number , arg1 ID function ) SR1 SequenceR [11, 66, 68] setTimeout ( Number_1 , Method_1 )

show abstract