Automatic bug fixing: Difference between revisions

Revision as of 08:24, 12 December 2020

Revision as of 05:49, 14 December 2020

Line 1:

'''Automatic bug-fixing''' is the automatic [[Patch (computing)|repair]] of [[software bug]]s without the intervention of a human programmer.<ref>{{cite journal |last1=Rinard |first1=Martin C. |year=2008 |title=Technical perspective ''Patching'' program errors |journal=Communications of the ACM |volume=51 |issue=12 |pages=86 |doi=10.1145/1409360.1409381 |s2cid=28629846 }}</ref><ref>{{cite journal |last1=Harman |first1=Mark |year=2010 |title=Automated patching techniques |journal=Communications of the ACM |volume=53 |issue=5 |pages=108 |doi=10.1145/1735223.1735248 |s2cid=9729944 }}</ref> It is also commonly referred to as ''automatic patch generation'', ''automatic bug repair'', or ''automatic program repair''.<ref name="Monperrus2018">{{cite journal |last1=Monperrus |first1=Martin |year=2018 |title=Automatic Software Repair |journal=ACM Computing Surveys |volume=51 |issue=1 |pages=1–24 |arxiv=1807.00515 |bibcode= |doi=10.1145/3105906 |s2cid=216145256 }}</ref><ref name="Gazzola2019">{{cite journal |last1=Gazzola |first1=Luca |last2=Micucci |first2=Daniela |last3=Mariani |first3=Leonardo |year=2019 |title=Automatic Software Repair: A Survey |journal=IEEE Transactions on Software Engineering |volume=45 |issue=1 |pages=34–67 |bibcode= |doi=10.1109/TSE.2017.2755013 |url=https://boa.unimib.it/bitstream/10281/184798/2/08089448_final.pdf |hdl=10281/184798 |s2cid=57764123 }}</ref> The typical goal of such techniques is to automatically generate correct [[Patch (computing)|patches]] to eliminate [[software bug|bugs]] in [[software program]]s without causing [[software regression]].<ref>{{cite book |last1=Tan |first1=Shin Hwei |last2=Roychoudhury |first2=Abhik |date=2015 |chapter=relifix: Automated repair of software regressions |title=2015 IEEE/ACM 37th IEEE International Conference on Software Engineering |publisher=IEEE |pages=471–482 |doi=10.1109/ICSE.2015.65 |isbn=978-1-4799-1934-5 |s2cid=17125466 }}</ref>

== Specification ==

Line 7:

A test-suite – the input/output pairs specify the functionality of the program, possibly captured in [[Assertion (software development)|assertions]] can be used as a [[test oracle]] to drive the search. This oracle can in fact be divided between the ''bug oracle'' that exposes the faulty behavior, and the ''regression oracle'', which encapsulates the functionality any program repair method must preserve. Note that a test suite is typically incomplete and does not cover all possible cases. Therefore, it is often possible for a validated patch to produce expected outputs for all inputs in the test suite but incorrect outputs for other inputs.<ref name="kali">{{cite book|title=Proceedings of the 2015 International Symposium on Software Testing and Analysis|last1=Qi|first1=Zichao|last2=Long|first2=Fan|last3=Achour|first3=Sara|last4=Rinard|first4=Martin|date=2015|publisher=ACM|isbn=978-1-4503-3620-8|chapter=An Anlysis of Patch Plausibility and Correctness for Generate-and-Validate Patch Generation Systems|citeseerx=10.1.1.696.5616|doi=10.1145/2771783.2771791|s2cid=6845282}}</ref> The existence of such validated but incorrect patches is a major challenge for generate-and-validate techniques.<ref name="kali" /> Recent successful automatic bug-fixing techniques often rely on additional information other than the test suite, such as information learned from previous human patches, to further identify correct patches among validated patches.<ref name="prophet">{{cite book|title=Proceedings of the 43rd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages|last1=Long|first1=Fan|last2=Rinard|first2=Martin|date=2016|publisher=ACM|isbn=978-1-4503-3549-2|pages=298–312|chapter=Automatic patch generation by learning correct code|doi=10.1145/2837614.2837617|s2cid=6091588}}</ref>

Another way to specify the expected behavior is to use [[formal specification]]s<ref name="autofixe">{{cite journal|last1=Pei|first1=Yu|last2=Furia|first2=Carlo A.|last3=Nordio|first3=Martin|last4=Wei|first4=Yi|last5=Meyer|first5=Bertrand|last6=Zeller|first6=Andreas|date=May 2014|title=Automated Fixing of Programs with Contracts|journal= IEEE Transactions on Software Engineering|volume=40|issue=5|pages=427–449|arxiv=1403.1117|doi=10.1109/TSE.2014.2312918|ref=harv|bibcode=2014arXiv1403.1117P|s2cid=53302638}}</ref><ref>{{cite journal|title=Contract-based Data Structure Repair Using Alloy|citeseerx=10.1.1.182.4390}}</ref> Verification against full specifications that specify the whole program behavior including functionalities is less common because such specifications are typically not available in practice and the computation cost of such [[formal verification|verification]] is prohibitive. For specific classes of errors, however, implicit partial specifications are often available. For example, there are targeted bug-fixing techniques validating that the patched program can no longer trigger overflow errors in the same execution path.<ref name="codephage" />

== Techniques ==

Line 13:

=== Generate-and-validate ===

Generate-and-validate approaches compile and test each candidate patch to collect all validated patches that produce expected outputs for all inputs in the test suite.<ref name="genprog2009" /><ref name="kali" /> Such a technique typically starts with a test suite of the program, i.e., a set of [[test cases]], at least one of which exposes the bug.<ref name="genprog2009" /><ref name="prophet" /><ref name="rsrepair">{{cite book |last1=Qi |first1=Yuhua |last2=Mao |first2=Xiaoguang |last3=Lei |first3=Yan |last4=Dai |first4=Ziying |last5=Wang |first5=Chengsong |date=2014 |chapter=The Strength of Random Search on Automated Program Repair |title=Proceedings of the 36th International Conference on Software Engineering |series=ICSE 2014 |___location=Austin, Texas |publisher=ACM |pages=254–265 |isbn=978-1-4503-2756-5 |doi=10.1145/2568225.2568254 |s2cid=14976851 |ref=harv}}</ref><ref name="spr">{{cite book |last1=Long |first1=Fan |last2=Rinard |first2=Martin |date=2015 |chapter=Staged Program Repair with Condition Synthesis |title=Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering |series=ESEC/FSE 2015 |___location=Bergamo, Italy |publisher=ACM |pages=166–178 |isbn=978-1-4503-3675-8 |doi=10.1145/2786805.2786811 |ref=harv|citeseerx=10.1.1.696.9059 |s2cid=5987616 }}</ref> An early generate-and-validate bug-fixing systems is GenProg.<ref name="genprog2009" /> The effectiveness of generate-and-validate techniques remains controversial, because they typically do not provide [[#Limitations of automatic bug-fixing|patch correctness guarantees]].<ref name="kali" /><ref name="criticalreview">{{cite book|title=Proceedings of the 36th International Conference on Software Engineering|last=Monperrus|first=Martin|date=2014|publisher=ACM|isbn=978-1-4503-2756-5|series=ICSE 2014|___location=New York, New York|pages=234–242|chapter=A Critical Review of "Automatic Patch Generation Learned from Human-written Patches": Essay on the Problem Statement and the Evaluation of Automatic Software Repair|arxiv=1408.2103|doi=10.1145/2568225.2568324|s2cid=13355761|ref=harv}}</ref> Nevertheless, the reported results of recent state-of-the-art techniques are generally promising. For example, on systematically collected 69 real world bugs in eight large C software programs, the state-of-the-art bug-fixing system Prophet generates correct patches for 18 out of the 69 bugs.<ref name="prophet" />

<!-- mutation based repair -->

Line 26:

=== Synthesis-based ===

Repair techniques exist that are based on symbolic execution. For example, Semfix<ref name="semfix">{{cite book|title=Proceedings of the 2013 International Conference on Software Engineering|last1=Nguyen|first1=Hoang Duong Thien|last2=Qi|first2=Dawei|last3=Roychoudhury|first3=Abhik|last4=Chandra|first4=Satish|date=2013|publisher=IEEE Press|isbn=978-1-4673-3076-3|series=ICSE '13'|___location=San Francisco, California|pages=772–781|chapter=SemFix: Program Repair via Semantic Analysis|ref=harv}}</ref> uses symbolic execution to extract a repair constraint. Angelix<ref name="angelix">{{cite book|title=Proceedings of the 38th International Conference on Software Engineering, ICSE 2016, Austin, Texas, May 14-22, 2016|last1=Mechtaev|first1=Sergey|last2=Yi|first2=Jooyong|last3=Roychoudhury|first3=Abhik|date=2016|pages=691–701|chapter=Angelix: scalable multiline program patch synthesis via symbolic analysis|ref=harv}}</ref> introduced the concept of angelic forest in order to deal with multiline patches.

<!-- repair and synthesis -->

Line 34:

</ref> uses dynamic synthesis.<ref>{{Cite book|last1=Galenson|first1=Joel|last2=Reames|first2=Philip|last3=Bodik|first3=Rastislav|last4=Hartmann|first4=Björn|last5=Sen|first5=Koushik|date=2014-05-31|title=CodeHint: dynamic and interactive synthesis of code snippets|publisher=ACM|pages=653–663|doi=10.1145/2568225.2568250|isbn=9781450327565|s2cid=10656182}}</ref>

S3<ref>{{Cite book|last1=Le|first1=Xuan-Bach D.|last2=Chu|first2=Duc-Hiep|last3=Lo|first3=David|last4=Le Goues|first4=Claire|last5=Visser|first5=Willem|date=2017-08-21|publisher=ACM|pages=593–604|doi=10.1145/3106237.3106309|title=Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering - ESEC/FSE 2017|isbn=9781450351058|s2cid=1503790|url=https://ink.library.smu.edu.sg/sis_research/3917}}</ref> is based on syntax-guided synthesis.<ref>{{Cite book |doi=10.1109/fmcad.2013.6679385|isbn=9780983567837|citeseerx=10.1.1.377.2829|chapter=Syntax-guided synthesis|title=2013 Formal Methods in Computer-Aided Design|pages=1–8|year=2013|last1=Alur|first1=Rajeev|last2=Bodik|first2=Rastislav|last3=Juniwal|first3=Garvit|last4=Martin|first4=Milo M. K.|last5=Raghothaman|first5=Mukund|last6=Seshia|first6=Sanjit A.|last7=Singh|first7=Rishabh|last8=Solar-Lezama|first8=Armando|last9=Torlak|first9=Emina|last10=Udupa|first10=Abhishek}}</ref>

SearchRepair<ref name="searchrepair">{{cite book|title=Proceedings of the 2015 30th IEEE/ACM International Conference on Automated Software Engineering|last1=Ke|first1=Yalin|last2=Stolee|first2=Kathryn|last3=Le Goues|first3=Claire|last4=Brun|first4=Yuriy|date=2015|publisher=ACM|isbn=978-1-5090-0025-8|series=ASE 2015|___location=Lincoln, Nebraska|pages=295–306|chapter=Repairing Programs with Semantic Code Search|doi=10.1109/ASE.2015.60|s2cid=16361458|ref=harv}}</ref> converts potential patches into an SMT formula and queries candidate patches that allow the patched program to pass all supplied test cases.

=== Data-driven ===

Line 43:

=== Other ===

Targeted automatic bug-fixing techniques generate repairs for specific classes of errors such as [[null pointer exception]]<ref name="rcv">{{cite book |last1=Long |first1=Fan |last2=Sidiroglou-Douskos |first2=Stelios |last3=Rinard |first3=Martin |date=2014 |chapter=Automatic Runtime Error Repair and Containment via Recovery Shepherding |title=Proceedings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implementation |series=PLDI '14' |___location=New York, New York |publisher=ACM |pages=227–238 |isbn=978-1-4503-2784-8 |doi=10.1145/2594291.2594337 |s2cid=6252501 |ref=harv}}</ref><ref name="nullfix">{{Cite book |doi = 10.1109/ISSRE.2008.59|chapter = Changing Java's Semantics for Handling Null Pointer Exceptions|title = 2008 19th International Symposium on Software Reliability Engineering (ISSRE)|pages = 47–56|year = 2008|last1 = Dobolyi|first1 = Kinga|last2 = Weimer|first2 = Westley|citeseerx = 10.1.1.147.6158|s2cid = 1454939}}</ref><ref name="par">{{cite book |last1=Kim |first1=Dongsun |last2=Nam |first2=Jaechang |last3=Song |first3=Jaewoo |last4=Kim |first4=Sunghun |date=2013 |chapter=Automatic Patch Generation Learned from Human-written Patches |title=Proceedings of the 2013 International Conference on Software Engineering |series=ICSE '13' |publisher=IEEE Press |pages=802–811 |isbn=978-1-4673-3076-3 |ref=harv}}</ref> [[integer overflow]] ,<ref name="codephage">{{cite book |last1=Sidiroglou |first1=Stelios |last2=Lahtinen |first2=Eric |last3=Long |first3=Fan |last4=Rinard |first4=Martin |date=2015 |chapter=Automatic Error Elimination by Multi-Application Code Transfer |title=Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation |ref=harv}}</ref> [[buffer overflow]] ,<ref name="codephage" /> [[memory leak]] ,<ref name="leakfix">{{cite book |last1=Gao |first1=Qing |last2=Xiong |first2=Yingfei |last3=Mi |first3=Yaqing |last4=Zhang |first4=Lu |last5=Yang |first5=Weikun |last6=Zhou |first6=Zhaoping |last7=Xie |first7=Bing |last8=Mei |first8=Hong |date=2015 |chapter=Safe Memory-leak Fixing for C Programs |title=Proceedings of the 37th International Conference on Software Engineering – Volume 1 |series=ICSE '15' |___location=Piscataway, New Jersey |publisher=IEEE Press |pages=459–470 |isbn=978-1-4799-1934-5 |ref=harv}}</ref> etc.. Such techniques often use empirical fix templates to fix bugs in the targeted scope. For example, insert a [[Conditional (computer programming)|conditional statement]] to check whether the value of a variable is null<ref name="par" /> or insert missing memory deallocation statements.<ref name="leakfix" /> Comparing to generate-and-validate techniques, targeted techniques tend to have better bug-fixing accuracy but a much narrowed scope.<ref name="kali" /><ref name="leakfix" />

== Use ==

Line 54:

== Search space ==

In essence, automatic bug fixing is a search activity, whether deductive-based or heuristic-based. The search space of automatic bug fixing is composed of all edits that can be possibly made to a program. There have been studies to understand the structure of this search space. Qi et al.<ref>{{Cite book|last1=Qi|first1=Yuhua|last2=Mao|first2=Xiaoguang|last3=Lei|first3=Yan|last4=Dai|first4=Ziying|last5=Wang|first5=Chengsong|date=2014-05-31|title=The strength of random search on automated program repair|publisher=ACM|pages=254–265|doi=10.1145/2568225.2568254|isbn=9781450327565|s2cid=14976851}}</ref> showed that the original fitness function of Genprog is not better than random search to drive the search. Martinez et al.<ref>{{Cite journal|last1=Martinez|first1=Matias|last2=Monperrus|first2=Martin|date=2013-11-28|title=Mining software repair models for reasoning on the search space of automated program fixing|url=https://hal.archives-ouvertes.fr/hal-00903808/document|journal=Empirical Software Engineering|language=en|volume=20|issue=1|pages=176–205|doi=10.1007/s10664-013-9282-8|issn=1382-3256|via=|arxiv=1311.3414|bibcode=2013arXiv1311.3414M|s2cid=1676168}}</ref> explored the imbalance between possible repair actions, showing its significant impact on the search. Long et al.'s<ref name="spaceanalysis" /> study indicated that correct patches can be considered as sparse in the search space and that incorrect overfitting patches are vastly more abundant (see also discussion about overfitting below).

If one explicitly enumerates all possible variants in a repair algorithm, this defines a design space for program repair.<ref name="Martinez2019">{{Cite journal|last1=Martinez|first1=Matias|last2=Monperrus|first2=Martin|title=Astor: Exploring the design space of generate-and-validate program repair beyond GenProg|journal=Journal of Systems and Software|volume=151|pages=65–80|doi=10.1016/j.jss.2019.01.069|date=2019|arxiv=1802.03365|s2cid=3619320}}</ref> Each variant selects an algorithm involved at some point in the repair process (eg the fault localization algorithm), or selects a specific heuristic which yields different patches. For instance, in the design space of generate-and-validate program repair, there is one variation point about the granularity of the program elements to be modified: an expression, a statement, a block, etc.<ref name="Martinez2019"/>

Line 60:

== Limitations of automatic bug-fixing ==

Automatic bug-fixing techniques that rely on a test suite do not provide patch correctness guarantees, because the test suite is incomplete and does not cover all cases.<ref name="kali" /> A weak test suite may cause generate-and-validate techniques to produce validated but incorrect patches that have negative effects such as eliminating desirable functionalities, causing memory leaks, and introducing security vulnerabilities.<ref name="kali" /> One possible approach is to amplify the failing test suite by automatically generating further test cases that are then labelled as passing or failing. To minimize the human labelling effort, an automatic [[test oracle]] can be trained that gradually learns to automatically classify test cases as passing or failing and only engages the bug-reporting user for uncertain cases.<ref name="learn2fix">{{cite book|title=Proceedings of the 13th International Conference on Software Testing, Validation and Verification|series=ICST 2020|___location=Porto, Portugal|publisher=IEEE|doi=10.1109/ICST46399.2020.00036|last1=Böhme|first1=Marcel|last2=Geethal|first2=Charaka|last3=Pham|first3=Van-Thuan|date=2020|pages=274–285|chapter=Human-In-The-Loop Automatic Program Repair|ref=harv|arxiv=1912.07758|isbn=978-1-7281-5778-8|s2cid=209386817}}</ref>

Sometimes, in test-suite based program repair, tools generate patches that pass the test suite, yet are actually incorrect, this is known as the "overfitting" problem.<ref name=overfitting>{{cite book |last1=Smith |first1=Edward K. |last2=Barr |first2=Earl T. |last3=Le Goues |first3=Claire |last4=Brun |first4=Yuriy |date=2015 |chapter=Is the Cure Worse Than the Disease? Overfitting in Automated Program Repair |title=Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering |series=ESEC/FSE 2015 |___location=New York, New York |publisher=ACM |pages=532–543 |isbn=978-1-4503-3675-8 |doi=10.1145/2786805.2786825 |s2cid=6300790 |ref=harv}}</ref> "Overfitting" in this context refers to the fact that the patch overfits to the test inputs. There are different kinds of overfitting:<ref name="Yu2018">{{cite journal|last1=Yu|first1=Zhongxing|last2=Martinez|first2=Matias|last3=Danglot|first3=Benjamin|last4=Durieux|first4=Thomas|last5=Monperrus|first5=Martin|title=Alleviating patch overfitting with automatic test generation: a study of feasibility and effectiveness for the Nopol repair system|journal=Empirical Software Engineering|volume=24|pages=33–67|year=2018|issn=1382-3256|doi=10.1007/s10664-018-9619-4|arxiv=1810.10614|bibcode=2018arXiv181010614Y|s2cid=21659819}}</ref> incomplete fixing means that only some buggy inputs are fixed, regression introduction means some previously working features are broken after the patch (because they were poorly tested). Early prototypes for automatic repair suffered a lot from overfitting: on the Manybugs C benchmark, Qi et al.<ref name="kali" /> reported that 104/110 of plausible GenProg patches were overfitting; on the Defects4J Java benchmark, Martinez et al.<ref name="martinezdefects4j">{{Cite journal|last1=Martinez|first1=Matias|last2=Durieux|first2=Thomas|last3=Sommerard|first3=Romain|last4=Xuan|first4=Jifeng|last5=Monperrus|first5=Martin|date=2016-10-25|title=Automatic repair of real bugs in java: a large-scale experiment on the defects4j dataset|url=https://hal.archives-ouvertes.fr/hal-01387556/document|journal=Empirical Software Engineering|language=en|volume=22|issue=4|pages=1936–1964|doi=10.1007/s10664-016-9470-4|issn=1382-3256|via=|arxiv=1811.02429|s2cid=24538587}}</ref> reported that 73/84 plausible patches as overfitting. In the context of synthesis-based repair, Le et al.<ref>{{Cite journal|last1=Le|first1=Xuan Bach D.|last2=Thung|first2=Ferdian|last3=Lo|first3=David|last4=Goues|first4=Claire Le|date=2018-03-02|title=Overfitting in semantics-based automated program repair|journal=Empirical Software Engineering|language=en|volume=23|issue=5|pages=3007–3033|doi=10.1007/s10664-017-9577-2|s2cid=3635768|issn=1382-3256|url=https://ink.library.smu.edu.sg/sis_research/3986}}</ref> obtained more than 80% of overfitting patches.

Another limitation of generate-and-validate systems is the search space explosion.<ref name=spaceanalysis>{{cite book |last1=Long |first1=Fan |last2=Rinard |first2=Martin |date=2016 |chapter=An Analysis of the Search Spaces for Generate and Validate Patch Generation Systems |title=Proceedings of the 38th International Conference on Software Engineering |series=ICSE '16 |___location=New York, New York |publisher=ACM |pages=702–713 |isbn=978-1-4503-3900-1 |doi=10.1145/2884781.2884872 |ref=harv|hdl=1721.1/113656 |arxiv=1602.05643 |s2cid=7426809 }}</ref> For a program, there are a large number of statements to change and for each statement there are a large number of possible modifications. State-of-the-art systems address this problem by assuming that a small modification is enough for fixing a bug, resulting in a search space reduction.

The limitation of approaches based on symbolic analysis<ref name="semfix" /><ref name="angelix" /> is that real world programs are often converted to intractably large formulas especially for modifying statements with [[side effect (computer science)|side effects]].

Line 87:

* LeakFix:<ref name=leakfix /> A tool that automatically fixes memory leaks in C programs.

* Prophet:<ref name=prophet /> The first generate-and-validate tool that uses machine learning techniques to learn useful knowledge from past human patches to recognize correct patches. It is evaluated on the same benchmark as GenProg and generate correct patches (i.e., equivalent to human patches) for 18 out of 69 cases.<ref name=prophet />

* SearchRepair:<ref name=searchrepair /> A tool for replacing buggy code using snippets of code from elsewhere. It is evaluated on the IntroClass benchmark<ref name=introclassmanybugs>{{Cite journal |last1=Le Goues |first1=Claire |last2=Holtschulte |first2=Neal |last3=Smith |first3=Edward |last4=Brun |first4=Yuriy |last5=Devanbu |first5=Premkumar |last6=Forrest |first6=Stephanie |last7=Weimer |first7=Westley |date=2015 |title= The Many ''Bugs'' and Intro ''Class'' Benchmarks for Automated Repair of C Programs|journal=IEEE Transactions on Software Engineering |volume=41 |issue=12 |pages=1236–1256 |doi=10.1109/TSE.2015.2454513 |ref=harv|doi-access=free }}</ref> and generates much higher quality patches on that benchmark than GenProg, RSRepair, and AE.

* Angelix:<ref name=angelix /> An improved solver-based bug-fixing tool. It is evaluated on the GenProg benchmark. For 10 out of the 69 cases, it generate patches that is equivalent to human patches.

* Learn2Fix:<ref name=learn2fix /> The first human-in-the-loop semi-automatic repair tool. Extends GenProg to learn the condition under which a semantic bug is observed by systematic queries to the user who is reporting the bug. Only works for programs that take and produce integers.

Line 94:

* PAR:<ref name=par /> A generate-and-validate tool that uses a set of manually defined fix templates. A later study raised concerns about the generalizability of the fix templates in PAR.<ref name=criticalreview />

* NOPOL:<ref name=nopol>{{cite journal |last1=Xuan |first1=Jifeng |last2=Martinez |first2=Matias |last3=DeMarco |first3=Favio |last4=Clément |first4=Maxime |last5=Lamelas |first5=Sebastian |last6=Durieux |first6=Thomas |last7=Le Berre |first7=Daniel |last8=Monperrus |first8=Martin |date=2016 |title=Nopol: Automatic Repair of Conditional Statement Bugs in Java Programs |journal=IEEE Transactions on Software Engineering |volume=43 |pages=34–55 |doi=10.1109/TSE.2016.2560811 |url=https://hal.archives-ouvertes.fr/hal-01285008/document |ref=harv|arxiv=1811.04211 |s2cid=15132155 }}</ref> A solver-based tool focusing on modifying condition statements.

* QACrashFix:<ref name=QAFix>{{cite book |last1=Gao |first1=Qing |last2=Zhang |first2=Hansheng |last3=Wang |first3=Jie |last4=Xiong |first4=Yingfei |last5=Zhang |first5=Lu |last6=Mei |first6=Hong |date=2015 |chapter=Fixing Recurring Crash Bugs via Analyzing Q&A Sites |title= 2015 30th IEEE/ACM International Conference on Automated Software Engineering (ASE) |pages=307–318 |publisher=IEEE |doi=10.1109/ASE.2015.81|isbn=978-1-5090-0025-8 |s2cid=2513924 }}</ref> A tool that fixes Java crash bugs by mining fixes from Q&A web site.

* Astor:<ref name=astor>{{cite book |last1=Martinez |first1=Matias |last2=Monperrus |first2=Martin |date=2016 |chapter=ASTOR: A Program Repair Library for Java |title=Proceedings of ISSTA, Demonstration Track |pages=441–444 |doi=10.1145/2931037.2948705 |chapter-url=https://hal.archives-ouvertes.fr/hal-01321615/file/astor.pdf|isbn=978-1-4503-4390-9 |s2cid=7322935 }}</ref> An automatic repair library for Java, containing jGenProg, a Java implementation of GenProg.

* ARJA:<ref name=arja>{{cite journal |last1=Yuan |first1=Yuan|last2=Banzhaf |first2=Wolfgang |date=2020 |title=ARJA: Automated Repair of Java Programs via Multi-Objective Genetic Programming |journal=IEEE Transactions on Software Engineering |volume=46|issue=10|pages=1040-1067 |doi=10.1109/TSE.2018.2874648|url=https://doi.org/10.1109/TSE.2018.2874648|ref=harv|arxiv=1712.07804}}</ref> A repair tool for Java based on multi-objective genetic programming.

* NpeFix:<ref name=npefix>{{cite book |last1=Durieux |first1=Thomas |date=2017 |chapter=Dynamic Patch Generation for Null Pointer Exceptions Using Metaprogramming |title=2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER) |pages=349–358 |doi=10.1109/SANER.2017.7884635|isbn=978-1-5090-5501-2 |arxiv=1812.00409 |s2cid=2736203 }}</ref> An automatic repair tool for NullPointerException in Java, available [https://github.com/Spirals-Team/npefix on Github].