Automatic bug-fixing is the automatic repair of software bugs without the intervention of a human programmer.[1][2] It is also commonly referred to as automatic patch generation, automatic bug repair, or automatic program repair.[3][4] The typical goal of such techniques is to automatically generate correct patches to eliminate bugs in software programs without causing software regression.[5]

Specification

Automatic bug fixing is made according to a specification of the expected behavior which can be for instance a formal specification or a test suite.[6]

A test-suite – the input/output pairs specify the functionality of the program, possibly captured in 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.[7] The existence of such validated but incorrect patches is a major challenge for generate-and-validate techniques.[7] 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.[8]

Another way to specify the expected behavior is to use formal specifications[9][10] 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 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.[11]

Techniques

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.[6][7] 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.[6][8][12][13] An early generate-and-validate bug-fixing systems is GenProg.[6] The effectiveness of generate-and-validate techniques remains controversial, because they typically do not provide patch correctness guarantees.[7][14] 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.[8]

One way to generate candidate patches is to apply mutation operators on the original program. Mutation operators manipulate the original program, potentially via its abstract syntax tree representation, or a more coarse-grained representation such as operating at the statement-level or block-level. Earlier genetic improvement approaches operate at the statement level and carry out simple delete/replace operations such as deleting an existing statement or replacing an existing statement with another statement in the same source file.[6][15] Recent approaches use more fine-grained operators at the abstract syntax tree level to generate more diverse set of candidate patches.[8][13]

Another way to generate candidate patches consists of using fix templates. Fix templates are typically predefined changes for fixing specific classes of bugs.[16] Examples of fix templates include inserting a conditional statement to check whether the value of a variable is null to fix null pointer exception, or changing an integer constant by one to fix off-by-one errors.[16] It is also possible to automatically mine fix templates for generate-and-validate approaches.[17][18]

Many generate-and-validate techniques rely on the redundancy insight: the code of the patch can be found elsewhere in the application. This idea was introduced in the Genprog system, where two operators, addition and replacement of AST nodes, were based on code taken from elsewhere (i.e. adding an existing AST node). This idea has been validated empirically, with two independent studies that have shown that a significant proportion of commits (3%-17%) are composed of existing code.[19][20] Beyond the fact that the code to reuse exists somewhere else, it has also been shown that the context of the potential repair ingredients is useful: often, the donor context is similar to the recipient context.[21][22]

Synthesis-based

Repair techniques exist that are based on symbolic execution. For example, Semfix[23] uses symbolic execution to extract a repair constraint. Angelix[24] introduced the concept of angelic forest in order to deal with multiline patches.

Under certain assumptions, it is possible to state the repair problem as a synthesis problem. SemFix[23] and Nopol[25] uses component-based synthesis.[26] Dynamoth[27] uses dynamic synthesis.[28] S3[29] is based on syntax-guided synthesis.[30] SearchRepair[31] converts potential patches into an SMT formula and queries candidate patches that allow the patched program to pass all supplied test cases.

Data-driven

Machine learning techniques can improve the effectiveness of automatic bug-fixing systems.[8] One example of such techniques learns from past successful patches from human developers collected from open source repositories in GitHub and SourceForge.[8] It then use the learned information to recognize and prioritize potentially correct patches among all generated candidate patches.[8] Alternatively, patches can be directly mined from existing sources. Example approaches include mining patches from donor applications[11] or from QA web sites.[32] Learning can done online, aka continual learning, with the known precedent of online learning of patches from the stream of open source build results from continuous integration.[33]

SequenceR uses sequence-to-sequence learning on source code in order to generate one-line patches.[34] It defines a neural network architecture that works well with source code, with the copy mechanism that allows to produce patches with tokens that are not in the learned vocabulary. Those tokens are taken from the code of the Java class under repair.

Getafix[35] is a language-agnostic approach developed and used in production at Facebook. Given a sample of code commits where engineers fixed a certain kind of bug, it learns human-like fix patterns that apply to future bugs of the same kind. Besides using Facebook's own code repositories as training data, Getafix learnt some fixes from open source Java repositories. When new bugs get detected, Getafix applies its previously learnt patterns to produce candidate fixes and ranks them within seconds. It presents only the top-ranked fix for final validation by tools or an engineer, in order to save resources and ideally be so fast that no human time was spent on fixing the same bug, yet.

Other

Targeted automatic bug-fixing techniques generate repairs for specific classes of errors such as null pointer exception[36][37][16] integer overflow ,[11] buffer overflow ,[11] memory leak ,[38] etc.. Such techniques often use empirical fix templates to fix bugs in the targeted scope. For example, insert a conditional statement to check whether the value of a variable is null[16] or insert missing memory deallocation statements.[38] Comparing to generate-and-validate techniques, targeted techniques tend to have better bug-fixing accuracy but a much narrowed scope.[7][38]

Use

There are multiple uses of automatic bug fixing:

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.[47] showed that the original fitness function of Genprog is not better than random search to drive the search. Martinez et al.[48] explored the imbalance between possible repair actions, showing its significant impact on the search. Long et al.'s[49] 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.[50] Each variant selects an algorithm involved at some point in the repair process (e.g. 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.[50]

It is also possible to analyze whether known search spaces encompass existing commits.[51] Such a search space analysis means mining a software repository, this results in an approximation of the applicability and usefulness of a given repair algorithm.

Overfitting

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.[52] "Overfitting" in this context refers to the fact that the patch overfits to the test inputs. There are different kinds of overfitting:[53] 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.[7] reported that 104/110 of plausible GenProg patches were overfitting; on the Defects4J Java benchmark, Martinez et al.[54] reported that 73/84 plausible patches as overfitting. In the context of synthesis-based repair, Le et al.[55] obtained more than 80% of overfitting patches.

One way to avoid overfitting is to filter out the generated patches. This can be done based on dynamic analysis,[56] or static code analysis of the generated patches.[57] When a reference patch is available, a state of the art technique is to generate tests based on the patched version, such that the generated tests capture the expected behavior. While the sampling of the input domain by test generation is incomplete by construction, it has been shown to be effective at detecting overfitting patches, and even at finding human errors done during manual classification of patches.[58]

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.[7] 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.[7] 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.[59]

A limitation of generate-and-validate repair systems is the search space explosion.[49] 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[23][24] is that real world programs are often converted to intractably large formulas especially for modifying statements with side effects.

Benchmarks

Benchmarks of bugs typically focus on one specific programming language. In C, the Manybugs benchmark collected by GenProg authors contains 69 real world defects and it is widely used to evaluate many other bug-fixing tools for C.[15][8][13][24]

In Java, the main benchmark is Defects4J, initially explored by Martinez et al.,[54] and now extensively used in most research papers on program repair for Java.[22][60] Alternative benchmarks exist, such as the Quixbugs benchmark,[61] which contains original bugs for program repair.[62] Other benchmarks of Java bugs include Bugs.jar,[63] based on past commits, and BEARS[64] which is a benchmark of continuous integration build failures.

Example tools

Automatic bug-fixing is an active research topic in computer science. There are many implementations of various bug-fixing techniques especially for C and Java programs. Note that most of these implementations are research prototypes for demonstrating their techniques, i.e., it is unclear whether their current implementations are ready for industrial usage or not.

C

Java

Other languages

Proprietary

References

  1. ^ Rinard, Martin C. (2008). "Technical perspective Patching program errors". Communications of the ACM. 51 (12): 86. doi:10.1145/1409360.1409381. S2CID 28629846.
  2. ^ Harman, Mark (2010). "Automated patching techniques". Communications of the ACM. 53 (5): 108. doi:10.1145/1735223.1735248. S2CID 9729944.
  3. ^ Monperrus, Martin (2018). "Automatic Software Repair". ACM Computing Surveys. 51 (1): 1–24. arXiv:1807.00515. doi:10.1145/3105906. S2CID 216145256.
  4. ^ Gazzola, Luca; Micucci, Daniela; Mariani, Leonardo (2019). "Automatic Software Repair: A Survey" (PDF). IEEE Transactions on Software Engineering. 45 (1): 34–67. doi:10.1109/TSE.2017.2755013. hdl:10281/184798. S2CID 57764123.
  5. ^ Tan, Shin Hwei; Roychoudhury, Abhik (2015). "relifix: Automated repair of software regressions". 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering. IEEE. pp. 471–482. doi:10.1109/ICSE.2015.65. ISBN 978-1-4799-1934-5. S2CID 17125466.
  6. ^ a b c d e f Weimer, Westley; Nguyen, ThanhVu; Le Goues, Claire; Forrest, Stephanie (2009). "Automatically finding patches using genetic programming". Proceedings of the 31st International Conference on Software Engineering. IEEE. pp. 364–374. CiteSeerX 10.1.1.147.8995. doi:10.1109/ICSE.2009.5070536. ISBN 978-1-4244-3453-4. S2CID 1706697.
  7. ^ a b c d e f g h i Qi, Zichao; Long, Fan; Achour, Sara; Rinard, Martin (2015). "An Anlysis of Patch Plausibility and Correctness for Generate-and-Validate Patch Generation Systems". Proceedings of the 2015 International Symposium on Software Testing and Analysis. ACM. CiteSeerX 10.1.1.696.5616. doi:10.1145/2771783.2771791. ISBN 978-1-4503-3620-8. S2CID 6845282.
  8. ^ a b c d e f g h i j Long, Fan; Rinard, Martin (2016). "Automatic patch generation by learning correct code". Proceedings of the 43rd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages. ACM. pp. 298–312. doi:10.1145/2837614.2837617. ISBN 978-1-4503-3549-2. S2CID 6091588.
  9. ^ a b Pei, Yu; Furia, Carlo A.; Nordio, Martin; Wei, Yi; Meyer, Bertrand; Zeller, Andreas (May 2014). "Automated Fixing of Programs with Contracts". IEEE Transactions on Software Engineering. 40 (5): 427–449. arXiv:1403.1117. Bibcode:2014arXiv1403.1117P. doi:10.1109/TSE.2014.2312918. S2CID 53302638.
  10. ^ "Contract-based Data Structure Repair Using Alloy". CiteSeerX 10.1.1.182.4390. ((cite journal)): Cite journal requires |journal= (help)
  11. ^ a b c d e f Sidiroglou, Stelios; Lahtinen, Eric; Long, Fan; Rinard, Martin (2015). "Automatic Error Elimination by Multi-Application Code Transfer". Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation.
  12. ^ Qi, Yuhua; Mao, Xiaoguang; Lei, Yan; Dai, Ziying; Wang, Chengsong (2014). "The Strength of Random Search on Automated Program Repair". Proceedings of the 36th International Conference on Software Engineering. ICSE 2014. Austin, Texas: ACM. pp. 254–265. doi:10.1145/2568225.2568254. ISBN 978-1-4503-2756-5. S2CID 14976851.
  13. ^ a b c Long, Fan; Rinard, Martin (2015). "Staged Program Repair with Condition Synthesis". Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering. ESEC/FSE 2015. Bergamo, Italy: ACM. pp. 166–178. CiteSeerX 10.1.1.696.9059. doi:10.1145/2786805.2786811. ISBN 978-1-4503-3675-8. S2CID 5987616.
  14. ^ a b Monperrus, Martin (2014). "A Critical Review of "Automatic Patch Generation Learned from Human-written Patches": Essay on the Problem Statement and the Evaluation of Automatic Software Repair". Proceedings of the 36th International Conference on Software Engineering. ICSE 2014. New York, New York: ACM. pp. 234–242. arXiv:1408.2103. doi:10.1145/2568225.2568324. ISBN 978-1-4503-2756-5. S2CID 13355761.
  15. ^ a b c Le Goues, Claire; Dewey-Vogt, Michael; Forrest, Stephanie; Weimer, Westley (2012). "A Systematic Study of Automated Program Repair: Fixing 55 out of 105 Bugs for $8 Each". 2012 34th International Conference on Software Engineering (ICSE). IEEE. pp. 3–13. CiteSeerX 10.1.1.661.9690. doi:10.1109/ICSE.2012.6227211. ISBN 978-1-4673-1067-3. S2CID 10987936.
  16. ^ a b c d e Kim, Dongsun; Nam, Jaechang; Song, Jaewoo; Kim, Sunghun (2013). "Automatic Patch Generation Learned from Human-written Patches". Proceedings of the 2013 International Conference on Software Engineering. ICSE '13'. IEEE Press. pp. 802–811. ISBN 978-1-4673-3076-3.
  17. ^ Martinez, Matias; Monperrus, Martin (2018), "Ultra-Large Repair Search Space with Automatically Mined Templates: The Cardumen Mode of Astor", Search-Based Software Engineering, Springer International Publishing, pp. 65–86, arXiv:1712.03854, doi:10.1007/978-3-319-99241-9_3, ISBN 9783319992402, S2CID 49651730
  18. ^ Koyuncu, Anil; Liu, Kui; Bissyandé, Tegawendé F.; Kim, Dongsun; Klein, Jacques; Monperrus, Martin; Le Traon, Yves (2020). "FixMiner: Mining relevant fix patterns for automated program repair". Empirical Software Engineering. 25 (3): 1980–2024. arXiv:1810.01791. doi:10.1007/s10664-019-09780-z. S2CID 52915728.
  19. ^ Martinez, Matias; Weimer, Westley; Monperrus, Martin (2014). "Do the fix ingredients already exist? An empirical inquiry into the redundancy assumptions of program repair approaches". Proceedings of the 36th International Conference on Software Engineering. pp. 492–495. arXiv:1403.6322. doi:10.1145/2591062.2591114. ISBN 9781450327688. S2CID 9533437.
  20. ^ Barr, Earl T.; Brun, Yuriy; Devanbu, Premkumar; Harman, Mark; Sarro, Federica (2014). "The plastic surgery hypothesis". Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2014. pp. 306–317. CiteSeerX 10.1.1.646.9678. doi:10.1145/2635868.2635898. ISBN 9781450330565. S2CID 14002308.
  21. ^ White, Martin; Tufano, Michele; Martinez, Matias; Monperrus, Martin; Poshyvanyk, Denys (2019). "Sorting and Transforming Program Repair Ingredients via Deep Learning Code Similarities". 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER). pp. 479–490. arXiv:1707.04742. doi:10.1109/SANER.2019.8668043. ISBN 978-1-7281-0591-8. S2CID 13578285.
  22. ^ a b Wen, Ming; Chen, Junjie; Wu, Rongxin; Hao, Dan; Cheung, Shing-Chi (2018). "Context-aware patch generation for better automated program repair". Proceedings of the 40th International Conference on Software Engineering - ICSE '18. New York, New York, USA: ACM Press: 1–11. doi:10.1145/3180155.3180233. ISBN 9781450356381. S2CID 3374770.
  23. ^ a b c d Nguyen, Hoang Duong Thien; Qi, Dawei; Roychoudhury, Abhik; Chandra, Satish (2013). "SemFix: Program Repair via Semantic Analysis". Proceedings of the 2013 International Conference on Software Engineering. ICSE '13'. San Francisco, California: IEEE Press. pp. 772–781. ISBN 978-1-4673-3076-3.
  24. ^ a b c d Mechtaev, Sergey; Yi, Jooyong; Roychoudhury, Abhik (2016). "Angelix: scalable multiline program patch synthesis via symbolic analysis". Proceedings of the 38th International Conference on Software Engineering, ICSE 2016, Austin, Texas, May 14-22, 2016. pp. 691–701.
  25. ^ a b Xuan, Jifeng; Martinez, Matias; DeMarco, Favio; Clément, Maxime; Lamelas, Sebastian; Durieux, Thomas; Le Berre, Daniel; Monperrus, Martin (2016). "Nopol: Automatic Repair of Conditional Statement Bugs in Java Programs". IEEE Transactions on Software Engineering. 43: 34–55. arXiv:1811.04211. doi:10.1109/TSE.2016.2560811. S2CID 15132155.
  26. ^ Jha, Susmit; Gulwani, Sumit; Seshia, Sanjit A.; Tiwari, Ashish (2010-05-01). Oracle-guided component-based program synthesis. ACM. pp. 215–224. doi:10.1145/1806799.1806833. ISBN 9781605587196. S2CID 6344783.
  27. ^ Durieux, Thomas; Monperrus, Martin (2016-05-14). "DynaMoth". DynaMoth: dynamic code synthesis for automatic program repair (PDF). pp. 85–91. doi:10.1145/2896921.2896931. ISBN 9781450341516. S2CID 16025812.
  28. ^ Galenson, Joel; Reames, Philip; Bodik, Rastislav; Hartmann, Björn; Sen, Koushik (2014-05-31). CodeHint: dynamic and interactive synthesis of code snippets. ACM. pp. 653–663. doi:10.1145/2568225.2568250. ISBN 9781450327565. S2CID 10656182.
  29. ^ Le, Xuan-Bach D.; Chu, Duc-Hiep; Lo, David; Le Goues, Claire; Visser, Willem (2017-08-21). Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering - ESEC/FSE 2017. ACM. pp. 593–604. doi:10.1145/3106237.3106309. ISBN 9781450351058. S2CID 1503790.
  30. ^ Alur, Rajeev; Bodik, Rastislav; Juniwal, Garvit; Martin, Milo M. K.; Raghothaman, Mukund; Seshia, Sanjit A.; Singh, Rishabh; Solar-Lezama, Armando; Torlak, Emina; Udupa, Abhishek (2013). "Syntax-guided synthesis". 2013 Formal Methods in Computer-Aided Design. pp. 1–8. CiteSeerX 10.1.1.377.2829. doi:10.1109/fmcad.2013.6679385. ISBN 9780983567837.
  31. ^ a b Ke, Yalin; Stolee, Kathryn; Le Goues, Claire; Brun, Yuriy (2015). "Repairing Programs with Semantic Code Search". Proceedings of the 2015 30th IEEE/ACM International Conference on Automated Software Engineering. ASE 2015. Lincoln, Nebraska: ACM. pp. 295–306. doi:10.1109/ASE.2015.60. ISBN 978-1-5090-0025-8. S2CID 16361458.
  32. ^ a b Gao, Qing; Zhang, Hansheng; Wang, Jie; Xiong, Yingfei; Zhang, Lu; Mei, Hong (2015). "Fixing Recurring Crash Bugs via Analyzing Q&A Sites". 2015 30th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE. pp. 307–318. doi:10.1109/ASE.2015.81. ISBN 978-1-5090-0025-8. S2CID 2513924.
  33. ^ Baudry, Benoit; Chen, Zimin; Etemadi, Khashayar; Fu, Han; Ginelli, Davide; Kommrusch, Steve; Martinez, Matias; Monperrus, Martin; Ron Arteaga, Javier; Ye, He; Yu, Zhongxing (2021). "A Software-Repair Robot Based on Continual Learning". IEEE Software. 38 (4): 28–35. arXiv:2012.06824. doi:10.1109/MS.2021.3070743. ISSN 0740-7459. S2CID 229156186.
  34. ^ Chen, Zimin; Kommrusch, Steve James; Tufano, Michele; Pouchet, Louis-Noel; Poshyvanyk, Denys; Monperrus, Martin (2019). "SEQUENCER: Sequence-to-Sequence Learning for End-to-End Program Repair". IEEE Transactions on Software Engineering: 1. arXiv:1901.01808. doi:10.1109/TSE.2019.2940179. ISSN 0098-5589. S2CID 57573711.
  35. ^ a b Bader, Johannes; Scott, Andrew; Pradel, Michael; Chandra, Satish (2019-10-10). "Getafix: learning to fix bugs automatically". Proceedings of the ACM on Programming Languages. 3 (OOPSLA): 159:1–159:27. doi:10.1145/3360585.
  36. ^ Long, Fan; Sidiroglou-Douskos, Stelios; Rinard, Martin (2014). "Automatic Runtime Error Repair and Containment via Recovery Shepherding". Proceedings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implementation. PLDI '14'. New York, New York: ACM. pp. 227–238. doi:10.1145/2594291.2594337. ISBN 978-1-4503-2784-8. S2CID 6252501.
  37. ^ Dobolyi, Kinga; Weimer, Westley (2008). "Changing Java's Semantics for Handling Null Pointer Exceptions". 2008 19th International Symposium on Software Reliability Engineering (ISSRE). pp. 47–56. CiteSeerX 10.1.1.147.6158. doi:10.1109/ISSRE.2008.59. S2CID 1454939.
  38. ^ a b c d Gao, Qing; Xiong, Yingfei; Mi, Yaqing; Zhang, Lu; Yang, Weikun; Zhou, Zhaoping; Xie, Bing; Mei, Hong (2015). "Safe Memory-leak Fixing for C Programs". Proceedings of the 37th International Conference on Software Engineering – Volume 1. ICSE '15'. Piscataway, New Jersey: IEEE Press. pp. 459–470. ISBN 978-1-4799-1934-5.
  39. ^ Muşlu, Kıvanç; Brun, Yuriy; Holmes, Reid; Ernst, Michael D.; Notkin, David; Muşlu, Kıvanç; Brun, Yuriy; Holmes, Reid; Ernst, Michael D.; Notkin, David (19 October 2012). "Speculative analysis of integrated development environment recommendations, Speculative analysis of integrated development environment recommendations". ACM SIGPLAN Notices. 47 (10): 669, 669–682, 682. CiteSeerX 10.1.1.259.6341. doi:10.1145/2384616.2384665. ISSN 0362-1340. S2CID 5795141.
  40. ^ Urli, Simon; Yu, Zhongxing; Seinturier, Lionel; Monperrus, Martin (27 May 2018). "How to design a program repair bot?". How to design a program repair bot?: insights from the repairnator project. pp. 95–104. arXiv:1811.09852. doi:10.1145/3183519.3183540. ISBN 9781450356596. S2CID 49237449.
  41. ^ Monperrus, Martin (2019). "Explainable Software Bot Contributions: Case Study of Automated Bug Fixes". 2019 IEEE/ACM 1st International Workshop on Bots in Software Engineering (BotSE). pp. 12–15. arXiv:1905.02597. Bibcode:2019arXiv190502597M. doi:10.1109/BotSE.2019.00010. ISBN 978-1-7281-2262-5. S2CID 146808763.
  42. ^ Monperrus, Martin; Urli, Simon; Durieux, Thomas; Martinez, Matias; Baudry, Benoit; Seinturier, Lionel (2019). "Repairnator patches programs automatically". Ubiquity. 2019 (July): 1–12. arXiv:1910.06247. Bibcode:2019arXiv191006247M. doi:10.1145/3349589. S2CID 198986312.
  43. ^ a b Perkins, Jeff H.; et al. (2009). "Automatically patching errors in deployed software". Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles. ACM. pp. 87–102. CiteSeerX 10.1.1.157.5877. doi:10.1145/1629575.1629585. ISBN 978-1-60558-752-3. S2CID 7597529.
  44. ^ Durieux, Thomas; Hamadi, Youssef; Monperrus, Martin (2017). "Production-driven patch generation". 2017 IEEE/ACM 39th International Conference on Software Engineering: New Ideas and Emerging Technologies Results Track (ICSE-NIER). pp. 23–26. arXiv:1812.04475. doi:10.1109/icse-nier.2017.8. ISBN 978-1-5386-2675-7. S2CID 7737476.
  45. ^ Durieux, Thomas; Hamadi, Youssef; Monperrus, Martin (2018). "Fully Automated HTML and Javascript Rewriting for Constructing a Self-Healing Web Proxy". 2018 IEEE 29th International Symposium on Software Reliability Engineering (ISSRE). pp. 1–12. arXiv:1803.08725. Bibcode:2018arXiv180308725D. doi:10.1109/ISSRE.2018.00012. ISBN 978-1-5386-8321-7. S2CID 4268784.
  46. ^ Chen, Zimin; Kommrusch, Steve James; Monperrus, Martin (2022). "Neural Transfer Learning for Repairing Security Vulnerabilities in C Code". IEEE Transactions on Software Engineering: 1–1. doi:10.1109/TSE.2022.3147265. ISSN 0098-5589.
  47. ^ Qi, Yuhua; Mao, Xiaoguang; Lei, Yan; Dai, Ziying; Wang, Chengsong (2014-05-31). The strength of random search on automated program repair. ACM. pp. 254–265. doi:10.1145/2568225.2568254. ISBN 9781450327565. S2CID 14976851.
  48. ^ Martinez, Matias; Monperrus, Martin (2013-11-28). "Mining software repair models for reasoning on the search space of automated program fixing". Empirical Software Engineering. 20 (1): 176–205. arXiv:1311.3414. Bibcode:2013arXiv1311.3414M. doi:10.1007/s10664-013-9282-8. ISSN 1382-3256. S2CID 1676168.
  49. ^ a b Long, Fan; Rinard, Martin (2016). "An Analysis of the Search Spaces for Generate and Validate Patch Generation Systems". Proceedings of the 38th International Conference on Software Engineering. ICSE '16. New York, New York: ACM. pp. 702–713. arXiv:1602.05643. doi:10.1145/2884781.2884872. hdl:1721.1/113656. ISBN 978-1-4503-3900-1. S2CID 7426809.
  50. ^ a b Martinez, Matias; Monperrus, Martin (2019). "Astor: Exploring the design space of generate-and-validate program repair beyond GenProg". Journal of Systems and Software. 151: 65–80. arXiv:1802.03365. doi:10.1016/j.jss.2019.01.069. S2CID 3619320.
  51. ^ Etemadi, Khashayar; Tarighat, Niloofar; Yadav, Siddharth; Martinez, Matias; Monperrus, Martin (2022). "Estimating the potential of program repair search spaces with commit analysis". Journal of Systems and Software. 188: 111263. doi:10.1016/j.jss.2022.111263.
  52. ^ Smith, Edward K.; Barr, Earl T.; Le Goues, Claire; Brun, Yuriy (2015). "Is the Cure Worse Than the Disease? Overfitting in Automated Program Repair". Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering. ESEC/FSE 2015. New York, New York: ACM. pp. 532–543. doi:10.1145/2786805.2786825. ISBN 978-1-4503-3675-8. S2CID 6300790.
  53. ^ Yu, Zhongxing; Martinez, Matias; Danglot, Benjamin; Durieux, Thomas; Monperrus, Martin (2018). "Alleviating patch overfitting with automatic test generation: a study of feasibility and effectiveness for the Nopol repair system". Empirical Software Engineering. 24: 33–67. arXiv:1810.10614. Bibcode:2018arXiv181010614Y. doi:10.1007/s10664-018-9619-4. ISSN 1382-3256. S2CID 21659819.
  54. ^ a b Martinez, Matias; Durieux, Thomas; Sommerard, Romain; Xuan, Jifeng; Monperrus, Martin (2016-10-25). "Automatic repair of real bugs in java: a large-scale experiment on the defects4j dataset". Empirical Software Engineering. 22 (4): 1936–1964. arXiv:1811.02429. doi:10.1007/s10664-016-9470-4. ISSN 1382-3256. S2CID 24538587.
  55. ^ Le, Xuan Bach D.; Thung, Ferdian; Lo, David; Goues, Claire Le (2018-03-02). "Overfitting in semantics-based automated program repair". Empirical Software Engineering. 23 (5): 3007–3033. doi:10.1007/s10664-017-9577-2. ISSN 1382-3256. S2CID 3635768.
  56. ^ Xin, Qi; Reiss, Steven P. (2017-07-10). "Identifying test-suite-overfitted patches through test case generation". Proceedings of the 26th ACM SIGSOFT International Symposium on Software Testing and Analysis. New York, NY, USA: ACM: 226–236. doi:10.1145/3092703.3092718. ISBN 978-1-4503-5076-1. S2CID 20562134.
  57. ^ Ye, He; Gu, Jian; Martinez, Matias; Durieux, Thomas; Monperrus, Martin (2021). "Automated Classification of Overfitting Patches with Statically Extracted Code Features". IEEE Transactions on Software Engineering: 1. arXiv:1910.12057. doi:10.1109/tse.2021.3071750. ISSN 0098-5589. S2CID 204954907.
  58. ^ Ye, He; Martinez, Matias; Monperrus, Martin (2021). "Automated patch assessment for program repair at scale". Empirical Software Engineering. 26 (2): 20. arXiv:1909.13694. doi:10.1007/s10664-020-09920-w. ISSN 1382-3256. S2CID 203594006.
  59. ^ a b Böhme, Marcel; Geethal, Charaka; Pham, Van-Thuan (2020). "Human-In-The-Loop Automatic Program Repair". Proceedings of the 13th International Conference on Software Testing, Validation and Verification. ICST 2020. Porto, Portugal: IEEE. pp. 274–285. arXiv:1912.07758. doi:10.1109/ICST46399.2020.00036. ISBN 978-1-7281-5778-8. S2CID 209386817.
  60. ^ Hua, Jinru; Zhang, Mengshi; Wang, Kaiyuan; Khurshid, Sarfraz (2018). "Towards practical program repair with on-demand candidate generation". Proceedings of the 40th International Conference on Software Engineering - ICSE '18. New York, New York, USA: ACM Press: 12–23. doi:10.1145/3180155.3180245. ISBN 9781450356381. S2CID 49666327.
  61. ^ Lin, Derrick; Koppel, James; Chen, Angela; Solar-Lezama, Armando (2017). "QuixBugs: a multi-lingual program repair benchmark set based on the quixey challenge". Proceedings Companion of the 2017 ACM SIGPLAN International Conference on Systems, Programming, Languages, and Applications: Software for Humanity - SPLASH Companion 2017. New York, New York, USA: ACM Press: 55–56. doi:10.1145/3135932.3135941. ISBN 9781450355148.
  62. ^ Ye, He; Martinez, Matias; Durieux, Thomas; Monperrus, Martin (2021). "A comprehensive study of automatic program repair on the QuixBugs benchmark". Journal of Systems and Software. 171: 110825. arXiv:1805.03454. doi:10.1016/j.jss.2020.110825. ISSN 0164-1212. S2CID 221978135.
  63. ^ Saha, Ripon K.; Lyu, Yingjun; Lam, Wing; Yoshida, Hiroaki; Prasad, Mukul R. (2018). "Bugs.jar: a large-scale, diverse dataset of real-world Java bugs". Proceedings of the 15th International Conference on Mining Software Repositories. MSR '18: 10–13. doi:10.1145/3196398.3196473. ISBN 9781450357166. S2CID 50770093.
  64. ^ Madeiral, Fernanda; Urli, Simon; Maia, Marcelo; Monperrus, Martin (2019). "BEARS: An Extensible Java Bug Benchmark for Automatic Program Repair Studies". 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER). pp. 468–478. arXiv:1901.06024. doi:10.1109/SANER.2019.8667991. ISBN 978-1-7281-0591-8. S2CID 58028949.
  65. ^ Le Goues, Claire; Holtschulte, Neal; Smith, Edward; Brun, Yuriy; Devanbu, Premkumar; Forrest, Stephanie; Weimer, Westley (2015). "The Many Bugs and Intro Class Benchmarks for Automated Repair of C Programs". IEEE Transactions on Software Engineering. 41 (12): 1236–1256. doi:10.1109/TSE.2015.2454513.
  66. ^ Martinez, Matias; Monperrus, Martin (2016). "ASTOR: A Program Repair Library for Java" (PDF). Proceedings of ISSTA, Demonstration Track. pp. 441–444. doi:10.1145/2931037.2948705. ISBN 978-1-4503-4390-9. S2CID 7322935.
  67. ^ Yuan, Yuan; Banzhaf, Wolfgang (2020). "ARJA: Automated Repair of Java Programs via Multi-Objective Genetic Programming". IEEE Transactions on Software Engineering. 46 (10): 1040–1067. arXiv:1712.07804. doi:10.1109/TSE.2018.2874648. S2CID 25222219.
  68. ^ Durieux, Thomas (2017). "Dynamic Patch Generation for Null Pointer Exceptions Using Metaprogramming". 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER). pp. 349–358. arXiv:1812.00409. doi:10.1109/SANER.2017.7884635. ISBN 978-1-5090-5501-2. S2CID 2736203.
  69. ^ "AI is coming for your coding job". Sifted. Retrieved 2019-04-15.

External links

Categories