Toward Improving Ability to Repair Bugs Automatically–A Patch Candidate Location Mechanism Using Code Similarity–
Haruki Yokoyama, Yoshiki Higo, Keisuke Hotta, Takafumi Ohta,
Kozo Okano, and Shinji Kusumoto
Osaka University
1-5 Yamadaoka Suita Osaka, Japan{y-haruki,higo,k-hotta,t-ohta,okano,kusumoto}@ist.osaka-u.ac.jp
ABSTRACT

debugging consumes more than half of all the costs in software development [1].

Automated program repair is a promising way to reduce costs on
program debugging dramatically. Some repair techniques with genetic algorithm have been proposed, and they were able to ﬁx several dozen of actual bugs in open source software. However, existing techniques occasionally take a long time to generate a repaired
version of a given program. The dominant factor for that is generating so many programs that do not pass given test cases. In this research, we are trying to generate a repaired program, which passes
all the test cases, in less time. Our key idea is using code similarity to select code lines to be inserted into a given program. Moreconcretely, we propose to select code lines in code regions similar
to the faulty code regions. In existing techniques, code lines for insertion are randomly selected from a given program. Currently, weare still in an early stage of this research. In this paper, we report
some promising results of our pilot study, which show that usingcode similarity is very effective to generate repaired programs inless time.

A promising way to reduce the cost of debugging is automating it.
Debugging includes two tasks: one is locating the cause of a given
fault; the other is changing the located code to remove the fault.
Many research studies have been conducted on automating fault localization [5, 13]. On the other hand, automating code changes has
been attracting much attention recently. Automating code changes
to remove bugs is called as automated program repair. Automatedprogram repair techniques generate a variant program that passes
all the given test cases. Generating a variant program is an operation sequence of inserting, deleting, and replacing a code line on
a given original program. If a variant program passes all the given
test cases, it is regarded as a repaired version of the given program.
If a variant does not, another variant program is generated until the
bug is removed.
In recent years, some techniques using genetic programming haveshown their capabilities for automated program repair [7, 8, 11].
Such techniques also generate variant programs with insertion, deletion, and replacement operations. In the case of deletion, a faulty
code line identiﬁed by a fault localization technique is deleted,which is not time-consuming. On the other hand, in cases of insertion and replacement, a code line to be added is randomly selected from the source code of the given program. However, if a
program includes a huge number of lines in its source code, it is
difﬁcult to realize generating a repaired version of programs withrandom selection in a short time. In other words, some strategies toselect code lines for insertion is required for short-time generationsof repaired programs.

CCS Concepts•Software and its engineering → Automatic programming; Software notations and tools; Software libraries and repositories;

Keywords
Automated program repair, Source code analysis, Genetic programming

In this paper, we report that using code similarity can be an effective
strategy to select code lines for insertion. More concretely, after
locating faulty code region, selecting code lines from code regions
similar to the faulty code region is a way to generate a repaired
program in less time than random selection.

1. INTRODUCTION
Program debugging is one of the main activities of software evolution. Developers generally use a suite of positive and negative
test cases to check whether debugging has been completed or not.
Debugging is a cost-consuming activity and there is a report that
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies
are not made or distributed for proﬁt or commercial advantage and that
copies bear this notice and the full citation on the ﬁrst page. Copyrights for components of this work owned by others than ACM must
be honored. Abstracting with credit is permitted. To copy otherwise,or republish, to post on servers or to redistribute to lists, requires priorspeciﬁc permission and/or a fee. Request permissions from Permissions@acm.org.

2.

RELATED WORKSAC 2016,April 04-08, 2016, Pisa, Italy

There are some techniques for automatic program repair. The ﬁrst
technique is using genetic programming to generate repaired programs [7, 8, 11]. GenProg takes a suite of test cases as its inputs
and generates a repaired version of the program with genetic programming [7, 8]. In GenProg, variant programs are generated byusing three operations, mutation, crossover, and selection , whichis shown in Figure 1.

c2016ACM. ISBN 978-1-4503-3739-7/16/04. . . $15.00
DOI: http://dx.doi.org/10.1145/2851613.2851770

Mutation: an operation making a variant from a given program

1364



    )$!&! !   )

#)-/!  $  %&)-0!2 )-1!2 ).(! 2"   $%      ).)!2"$%     ).*!2$% ).+! $%     ).,!'#)/1!     $%&)0(! 2"   $%      )0)!$ 22(%
)0*! $% 
)0+!2"$%     )0,!
)0-! $%     )0.!'#Figure 1: Overview of GenProg

Figure 2: A motivating example""%!   (






by applying a small change. A small change is inserting,deleting, or replacing a code line.

Replacement: a combination of deletion and insertion. More concretely, a code line in the faulty region of a given program isdeleted and then a code line in the given program is selected
and inserted to the deleted position.

Crossover: an operation making two variant programs from given
two programs by randomly exchanging pieces of the representations of the two parents.

In insertion and replacement operations, code lines that already exist in a given program are reused to generate variant programs. Barret al. conducted an experiment to investigate the capability of suchreuse-based approaches on 12 open source software [2]. They revealed that 43% of inserted code lines in the development historiesof the 12 software had existed in their source code.

Selection: an operation to select some variant programs made with
mutation and crossover operations. The number of passed
test cases is a selecting standard for variant programs. Selected variant programs are used to make next-generation
variant programs.
All n-th generation variant programs made by mutation and crossover
operations are tested with the given suite of test cases. If a variant
program passed all the test cases, it is regarded as a repaired program. If there is no variant program that passes all the tests, aselect operation is applied to the n-th generation variant programs.
Selected variant programs are targets of mutation and crossover operations to make (n + 1)-th generation variant programs.
GenProg runs all the test cases for all the variant programs, so thatrunning test cases accounts for the dominant cost of GenProg’s runtime. As a countermeasure for this, RSRepair has been proposed[11]. RSRepair generates only a single variant program and running test cases for it. Unlike GenProg, if a variant program does
not pass any of the test cases, RSRepair does not run remaining

test cases. This strategy has advantages and disadvantages on generating repaired programs. One of the advantages is that RSRepair’s runtime is shorter than GenProg in cases where the both tools
can generate repaired programs. One of the disadvantages is that
RSRepair can generate repaired programs only if a given faulty program contains only a single bug. On the other hand, GenProg has acapability to generate repaired programs even if multiple bugs exist
in a given faulty program.

SemFix is a technique based on programming semantic theory [10].
It generates repaired programs by using logical expressions of properties that a given program must satisfy. SemFix is able to generate
repaired programs for faulty programs where GenProg is not able
to generate repaired programs. SemFix solves logical expressions
with SMT solver [3]. SMT problems are NP-complete, so that it is
difﬁcult to solve complex logical expressions.
PAR is a technique using human-written patches. It extracts code
patterns in patches and uses the patterns to generate a repaired version of a given faulty program [6]. Literature [6] reported PAR wasable to generate repaired versions for given faulty programs where
GenProg was not. However, there are critical discussions on PAR’s
experimental design [9].

3.

RESEARCH MOTIVATION

We manually investigated many bug-ﬁx commits in open source
software. We browsed inserted code lines into repaired versions
and the code regions including code lines identical to the inserted
ones. As a result, we found that such code regions are similar tothe code region surrounding the faulty code in many cases. Figure
2 shows an actual example. This is a part of a source ﬁle in JabRef
project at revision 3158. The 161st code line has been inserted
in the changes between revisions 3157 and 3158. We found that
there was a code line identical to the inserted code line in the same
source ﬁle. Besides, there are two common code lines in the twocode regions: the ﬁrst one is a code region surrounding the inserted
code line; the second one is a code region surrounding the code line
identical to the inserted one.

Mutation operation is common to GenProg and RSRepair. In theoperation, one of the following manupilations is randomly applied.
Deletion: a code line in the faulty code region of a given programis deleted.
Insertion: a code line in the given program is randomly selected,
and it is inserted to the faulty region of the program.

This fact lets us come up with an idea that using code similarity1365

might be a good strategy to select code lines for automatic program
repair. If so, we can shorten the time to generate repaired programs
when using automatic program repair techniques such as GenProg[7, 8] or RSRepair [11].

In order to evaluate the strategy to use code similarity, we investigate the following research questions.
RQ1: are code lines necessary for a repaired program located incode regions similar to the faulty code region?

!# %    

         !  ! ! "   ""      

RQ2: is it possible to calculate quickly similarities between thefaulty code region and code regions in the given program?

! $

#  4. EXPERIMENT  
 We conducted an experiment to answer the two RQs described in
Section 3.

  

In this experiment, we used bug-ﬁx commits, which are shown in
Table 1, in four open source software. Two of them (Apache HTTP
Server and CBMC) are written in C/C++ language and the othertwo (JabRef and jEdit) are written in Java language.

With the above phases, we collected 24 bug-ﬁx commits from thefour software. Table 1 includes the revision number just after thecommits, so that readers can easily use the same commits in theirresearch.

Table 1: Commits used in the experiment

HTTP

CBMC

JabRef

jEdit

Total

 

In the second phase, we manually checked if the picked-up commits are bug-ﬁx commits or not one by one.

• At least one of the inserted code lines in a given commit isgraftable. Here, a code line inserted by a given commit is

New
lines
3
13
8
13
1
3
4
3
2
1
9
1
1
6
11
3
2
3
3
2
5
1
8
9
115



graftable if there exists a code line in the source code before
committed that is identical to the inserted one.

• The commit message of a given commit includes at least oneof the following words: ﬁx, ﬁxed, and ﬁxing.

CommitLOC
Date
129,965
3/Feb/2012
131,536 27/Aug/2012
136,938
12/Dec/2012
136,982
16/Dec/2012
142,042
26/Sep/2013
125,598
31/Dec/2014
125,649
31/Dec/2014
125,673
1/Jan/2015
126,398
8/Jan/2015
128,734
8/Feb/2015
61,238
2/Feb/2010
61,2504/Feb/2010
62,522
15/Sep/2010
62,606
4/Nov/2010
63,32125/Mar/2011
64,429 11/May/2011
65,187 12/Aug/2011
69,657
10/Oct/2011
77,198 27/May/2012
77,101
6/Jun/2012
77,127
14/Jun/2012
77,1908/Jul/2012
77,203
13/Jul/2012
77,318 14/Aug/2012––"Figure 3: Overview of code coverage calculation

The bug-ﬁx commits were collected with two-phase operations. In
the ﬁrst phase, we picked up several dozen of commits satisfying
both the two conditions in an automated way.

Revision
r1240181
r1377647
r1421780
r1422373
r1526473
r4950
r4952
r4979
r5028
r5167
r3155
r3158
r3331
r3354
r3486
r3528
r3599
r3686
r21720r21768r21800r21918r21933r22000– 

$ 
 

4.1 Data Collection

Software
"Graftable
lines
2
9
3
7
1
1
1
2
2
1
4
1
1
4
5
1
1
2
2
2
2
1
8
4
67

The fourth column of Table 1 entitled “New lines” means the number of inserted code lines in the commits. The last column entitled“Graftable lines” means the number of graftable code lines in thecommits.

4.2

Data Analysis

We investigated whether each of the graftable lines in Table 1 wasin code regions similar to the faulty code region with an automaticway, which is shown in Figure 3. We used four lines, six lines, andeight lines as sizes of code region.
The procedure of the investigation for each bug-ﬁx commit consistsof the following six steps. A bug-ﬁx commit and a size of code
region are the inputs to the procedure. The investigation method
reports a value of code coverage for each of the inserted lines in
the given bug-ﬁx commit. A code coverage is a ratio of code lines
covered with a given set of code regions against the whole sourcecode. In other words, a code coverage for an inserted line means
how many code lines should be examined to ﬁnd the inserted line.
A low value of the code coverage means that a code line in code
regions similar to the faulty code region is identical to the inserted
code line in a given commit. The whole procedure is executed in
an automatic way.
STEP1: obtaining revisions before/after a given commit.

1366


  
    
!   
"'#&
$
%
  




             
    (a) Before

Figure 6: Collecting code regions from a source ﬁle(b) After
STEP4, STEP5, and STEP6 are performed on each of the inserted
code lines identiﬁed in STEP2. STEP4 is identifying the faulty
code region. The code region surrounding the inserted line is extracted as a given size. Note that the inserted code line itself is notincluded in the faulty code region. A faulty code region is identiﬁed to each of the inserted code lines. In the case of Figure 5, if
the size of code region is 4, the faulty code region for “changed 1” and “changed 2” is “ABCD” and the faulty code region for “added1” and “added 2 ” is “EFGH”.

Figure 4: An example of the normalization in the experiment                          



  





(a) Before(b) After(c) diff result

STEP5 is sorting code regions collected in STEP3 based on theirsimilarities to the faulty code identiﬁed in STEP4. The similarity
calculation between two code regions is performed with the following formula.
Similarity(Ta , Tb ) =|LCS(Ta , Tb )| × 2|Ta | + |Tb |(1)

Ta , Tb : token sequences in given two code regions a and b.

Figure 5: Identifying inserted lines with diff tool

LCS(Ta , Tb ): a longest common subsequence between two token
sequences Ta and Tb .

STEP2: extracting inserted code lines.

|T |: the number of tokens in a given token sequence T .

STEP3: collecting code regions.
After STEP5, the most similar code region is located at the top of
the sorted code regions. Here, we describe the sorted code regions
as a list R.

STEP4: identifying the faulty code region.
STEP5: sorting the code regions.

R = {r1 , r2 , · · · , rk , · · · , rn }STEP6: calculating a code coverage.
In the remainder of this subsection, we describe each of the steps
in detail.

(2)

STEP6 is calculating code coverage. We check sorted code regions
from the top of the list whether a code region includes the inserted
code line or not.

STEP1 is an easy operation. By specifying the ID (revision number) of a given commit, we can easily obtain its before and afterrevisions. All the source ﬁles of the revisions are retrieved because
they are used in STEP4. Obtained source ﬁles are normalized withthe following rules.

If code region rk is the nearest to the top in code regions including
the inserted code line, code regions in the sublist {r1 , r2 , · · · , rk }are used for calculating code coverage. Code coverage is calculatedby the following formula.
• Open and clone brackets (“{” and “}”) are removed.

Coverage(Rk ) =• Comments, blank lines, and indents are removed.

| r∈Rk L(r)|| r∈R L(r)|(3)

Rk : {r1 , r2 , · · · , rk }, which is a sublist from the top to code region
rk in R.

Figure 4 shows an example of our normalization.
STEP2 is identifying inserted code lines in the commit. The identiﬁcation is operated with UNIX diff tool. Identiﬁed inserted codelines are regarded as code lines necessary for repaired program.
Figure 5 shows an example of diff application. The code lines
starting with “>” are inserted ones.

L(r): a set of code lines in code region r.

4.3

Result and Discussion

Figure 7 shows boxplots of code coverages for the three sizes ofcode regions. Most of the code coverages are close to 0, whichmeans that code regions having graftable lines appeared almost the
top of the similar regions lists. For all the sizes, the 75 percentile isless than 0.1, which means 75% of graftable line is obtainable from

STEP3 is collecting code regions from the whole source code of the
before-commit revision. We extract all code regions with a given
window size one line by one line. Figure 6 depicts how code regions are extracted from a source ﬁle.

1367

Table 2: Detail code coverage for rare lines
Software

HTTP

CBMC

JabRef

r1422373
r1377647
r1377647
r1377647
r1377647
r1377647
r5028
r4979
r3686
r3599
r3528
r3486
r3486
r3486
r3354
r3354
r3331
r3158
r3155
r3155
r21933r21933r21933r21933r21933r21918r21800r21720# of the samecode lines
int i, rv;
8
pbktEOS = apr_bucket_eos_create(c->bucket_alloc);
7
apr_brigade_cleanup(pbbIn);
16
ctx->tmpBucket = apr_brigade_create(r->pool, c->bucket_alloc);
16
apr_bucket_delete(pbktIn);16
ret = apr_bucket_read(pbktIn, &data, &len, eBlock);16
if (base_type_eq(expr_type, op_type, *this))8
dest += convert(it->op0());
16
return pageParts[0];4return input;
20
sb.append(lastNamePart);6
pr.setInvalid(true);16
pr.setFile(file);
19
ParserResult pr = new ParserResult(null, null, null);8
if (postFormatter != null)
16
value = "";8
fileSize = file.length();16
fileSize = file.length();8
List<BibtexEntry> entries;
8
data[0].replaceAll("~", System.getProperty("user.home")));13
if (obj instanceof VFSFile)
16
Object obj = parentDirectories.getModel();16
VFSFile dirEntry = (VFSFile) obj;
16
focusOnFileView();8browser.setDirectory(dirEntry.getPath());
8case Frame.MAXIMIZED_BOTH:
8
CharsetEncoding utf8 = new CharsetEncoding("UTF-8");8
VFS vfsSrc = VFSManager.getVFSForPath(path);
8

Inserted code line

1.0

jEdit

Revision

Code coverage
6 code lines 8 code lines
16.19%
36.83%
0.03%
0.01%
0.26%
0.39%
2.37%
1.34%
0.12%
0.03%
0.06%
0.05%
5.10%
9.07%
0.09%
0.06%
0.01%
0.02%
0.68%
0.02%
0.01%
0.03%
16.30%
19.52%
1.92%
19.51%
1.92%
19.51%
0.43%
0.25%
96.83%
81.80%
0.03%
0.88%
0.01%
0.05%
82.81%
70.33%
0.01%
0.01%
13.07%
4.15%
13.07%
4.15%
17.99%
4.15%
15.73%
4.15%
15.73%
4.15%
3.97%
0.73%
7.08%
23.93%
55.14%
54.79%

0.8[8, 11]. As a result, we revealed that only a small number of codelines are reusable in many cases. Table 2 shows detail information
for the cases where 20 or fewer code lines are reusable.

0.4

0.6

For each inserted code line in the bug-ﬁx commits, code coverage
was calculated in an automatic way. We also measured its runtime.
Especially, in the runtime measurement, we focused on STEP4,
STEP5, and STEP6 because those steps are not included in existing techniques. In other words, if we add the proposed techniqueto GenProg, those steps are additional operations in its execution.
Table 3 shows the runtime of the sum of those steps for all the bugﬁx commits on three sizes of code regions. We can see that every

0.2

Code coverage

4 code lines
7.76%
0.05%
0.56%
3.00%
7.60%
0.53%
5.62%
0.01%
0.01%
39.66%
0.01%
36.45%
36.45%
0.58%
0.28%
100.00%0.10%
0.01%
96.51%
0.01%
24.06%
6.03%
16.87%
8.47%
8.47%
13.23%
8.79%
56.92%

0.0

Table 3: Runtime for the Commits used in the experiment
4 code lines

6 code lines

8 code lines

Software

Region size

HTTP

Figure 7: Code coverages on the target commits

CBMC

10% lines of the source code. The 10% lines are in code regions
similar to the give faulty code regions.

JabRef

We also checked the number of code lines that are reusable in thefaulty code lines because if so many code lines are reusable therandom selection is a nice strategy, which is used in existing works

jEdit

1368

Region size
4 code lines
6 code lines
8 code lines
4 code lines
6 code lines
8 code lines
4 code lines
6 code lines
8 code lines
4 code lines
6 code lines
8 code lines

Runtime (seconds)
Minimum Maximum Average
0.803
1.944
1.201
1.619
3.063
2.193
1.910
4.935
3.344
0.681
2.174
1.566
1.214
3.947
2.829
1.915
6.655
4.344
0.446
1.311
0.787
0.719
1.718
1.292
1.274
3.106
2.103
0.589
1.024
0.746
0.890
3.671
1.656
1.623
3.176
2.395

 #  
 
#$!  

   %  &  
 
#$"

%   &'%   &

Figure 8: Concept of our future researchto generate repaired programs with eight code lines may be
shorter than the time with four code lines. In the future, weare going to conduct more experiment with larger code regions to investigate runtime and code coverages.

calculation took only a few minutes.
Our answer to the RQ1 is YES. For more than 75% of graftablelines, there is a reusable code line in 10% of source code, which issimilar to the faulty code region.
Our answer to the RQ2 is also YES. It takes a few seconds to calculate code similarity between the faulty code region and all the code
regions in the source code.

5.

DIRECTIONS TO FUTURE RESEARCH

In the future, we are going to enlarge the selection target for codeline insertion. There is existing research reporting that 43% of inserted code lines in code changes is obtainable from its source codebase [2]. If we enlarge the selection target from a single software
to a huge set of source ﬁles, more code changes will be able to besupported by reusing existing code. We have conducted anotherexperiment on 122 Java projects on Apache Software Foundationand found that about half of code changes are common to multiple
projects [4].

Because of the positive answers to the RQs, we can conclude thatusing code similarity is effective and practical to select code lines
for insertion.

4.4 Threats to Validity
Here, we describe threats to validity in the experiment.
Bug-ﬁx commit: we collected bug-ﬁx commits by checking commits one by one. However, some commits might have been
misclassiﬁed as bug-ﬁx in the experiment because we are not
the developers of the target software. In order to avoid sucha mistake, a pair of the authors checked commits together.

Figure 8 shows a concept of our future research. It takes a faulty
code region and outputs code lines used for mutation. However, it is
not realistic to detect code regions similar to the given faulty code
region quickly by analyzing a huge set of the source code itself.
One promising way should be creating a code region database before detection. In the database, each code region in the huge dataset
is stored as a record. A record holds a set of hash values calculated
from its code region. A hash value is calculated from each codeline in a code region. When a faulty code region is given, hash values are calculated from its code lines. The hash values are used asa query to obtain similar code regions from the database. By using
this kind of scheme, we will be able to obtain quickly code lines
used for mutation from a huge set of source code.

Target software: we conducted the experiment only four software.
We selected the software as our targets because of three reasons. The ﬁrst reason is that they have been used in existing research related to automatic program repair. The second reason is their diversities of domains and programming
languages. The third reason is that it is not difﬁcult for theauthors to understand what each commit did in their repositories because the commit messages were well written. In the
future, we are going to conduct experiments on more software in the same fashion.

6.

Size of code region: we used four, six, and eight code lines as
sizes of code regions. The reason we used such small sizes
as code regions is to calculate code region similarities withlow calculation costs. The runtime with eight code lines wasapproximately three times as long as the runtime with four
code lines (see Table 3). On the other hand, the code coverages with eight code lines were slightly lower than the code
coverages with four code lines (see Figure 7). Thus, the time

CONCLUSION

GenProg [8] and RSRepair [11] are breakthrough for automatedprogram repair. However, they occasionally take a long time togenerate repaired programs. In this paper, in order to generate arepaired version of a given program in less time, we proposed touse code lines located in code regions similar to a given faulty code
region. We conducted a pilot study to evaluate its effectiveness on
generations of repaired programs in less time. The followings are
the main ﬁndings.

1369

• More than 75% of graftable code lines are obtainable from
10% lines of the source code. The 10% lines are located incode regions similar to the faulty code region.

[9] M. Monperrus. A Critical Review of "Automatic Patch
Generation Learned from Human-written Patches": Essay on
the Problem Statement and the Evaluation of Automatic
Software Repair. In Proceedings of the 36th International
Conference on Software Engineering, pages 234–242, 2014.
[10] H. D. T. Nguyen, D. Qi, A. Roychoudhury, and S. Chandra.
SemFix: Program Repair via Semantic Analysis. In
Proceedings of the 2013 International Conference on
Software Engineering, pages 772–781, 2013.
[11] Y. Qi, X. Mao, Y. Lei, Z. Dai, and C. Wang. The Strength ofRandom Search on Automated Program Repair. In
Proceedings of the 36th International Conference on
Software Engineering, pages 254–265, 2014.
[12] S. Sumi, Y. Higo, K. Hotta, and S. Kusumoto. Toward
Improving Graftability on Automated Program Repair. In
accepted by the 31st International Conference On Software
Maintenance and Evoluation, page (to appear), 2015.
[13] X. Wang, S. C. Cheung, W. K. Chan, and Z. Zhang. Taming
Coincidental Correctness: Coverage Reﬁnement with
Context Patterns to Improve Fault Localization. In
Proceedings of the 31st International Conference on
Software Engineering, pages 45–55, 2009.

• Calculating similarities between the faulty code and code regions in the source code takes only a short time. This processing does not become a big overhead to generate repaired
programs.
Currently, our research is still in an early stage. In the future, ﬁrstly,
we embed the proposed technique to GenProg and measure its actual performance with the proposed technique. We also plan toselect code lines for insertion from not only the same program but
also other programs. Enlarging reuse targets realize generating repaired programs for more bugs. Using code similarity will be a key
technique to select patch candidates from a large source code data.
We are also going to enhance our technique to reuse code lines
with identiﬁer normalizations. In another project, we have alreadyconﬁrmed the usefulness of the normalizations [12].

7. ACKNOWLEDGEMENTS
This work was supported by JSPS KAKENHI Grant Numbers 25220003
and 24680002.

8. REFERENCES[1] J. Baker. The gpl-violations.org project.
http://www.jbs.cam.ac.uk/media/2012/
cambridge-news-experts-battle-192-bn-loss-to-computer-bugs/,
Feb. 2012. Last accessed 20 April 2015.
[2] E. T. Barr, Y. Brun, P. Devanbu, M. Harman, and F. Sarro.
The Plastic Surgery Hypothesis. In Proceedings of the 22ndInternational Symposium on Foundations of Software
Engineering, pages 306–317, 2014.
[3] L. De Moura and N. Bjørner. Z3: An Efﬁcient SMT Solver.
In Proceedings of the Theory and Practice of Software, 14th
International Conference on Tools and Algorithms for theConstruction and Analysis of Systems, pages 337–340, 2008.
[4] Y. Higo, A. Ohtani, S. Hayashi, H. Hata, and S. Kusumoto.
Toward Reusing Code Changes. In Proceedings of the 12th
Working Conference on Mining Softwre Repositories, pages
52–56, 2015.
[5] J. A. Jones and M. J. Harrold. Empirical Evaluation of the
Tarantula Automatic Fault-localization Technique. In
Proceedings of the 20th IEEE/ACM International Conference
on Automated Software Engineering, pages 273–282, 2005.
[6] D. Kim, J. Nam, J. Song, and S. Kim. Automatic Patch
Generation Learned from Human-written Patches. In
Proceedings of the 2013 International Conference on
Software Engineering, pages 802–811, 2013.
[7] C. Le Goues, M. Dewey-Vogt, S. Forrest, and W. Weimer. A
Systematic Study of Automated Program Repair: Fixing 55
out of 105 Bugs for $8 Each. In Proceedings of the 34th
International Conference on Software Engineering, pages
3–13, 2012.
[8] C. Le Goues, T. Nguyen, S. Forrest, and W. Weimer.
GenProg: A Generic Method for Automatic Software Repair.
IEEE Transactions on Software Engineering, 38(1):54–72,
2012.

1370