Automatic bug fixing

Last updated

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] The typical goal of such techniques is to automatically generate correct patches to eliminate bugs in software programs without causing software regression. [4]

Contents

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

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. [6] The existence of such validated but incorrect patches is a major challenge for generate-and-validate techniques. [6] 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. [7]

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

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

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. [5] [13] Recent approaches use more fine-grained operators at the abstract syntax tree level to generate more diverse set of candidate patches. [12] Notably, the statement deletion mutation operator, and more generally removing code, is a reasonable repair strategy, or at least a good fault localization strategy. [14]

Another way to generate candidate patches consists of using fix templates. Fix templates are typically predefined changes for fixing specific classes of bugs. [15] 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. [15]

Synthesis-based

Repair techniques exist that are based on symbolic execution. For example, Semfix [16] uses symbolic execution to extract a repair constraint. Angelix [17] 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 [16] uses component-based synthesis. [18] Dynamoth uses dynamic synthesis. [19] S3 [20] is based on syntax-guided synthesis. [21] SearchRepair [22] 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. [7] One example of such techniques learns from past successful patches from human developers collected from open source repositories in GitHub and SourceForge. [7] It then use the learned information to recognize and prioritize potentially correct patches among all generated candidate patches. [7] Alternatively, patches can be directly mined from existing sources. Example approaches include mining patches from donor applications [10] or from QA web sites. [23]

Getafix [24] 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.

Template-based repair

For specific classes of errors, targeted automatic bug-fixing techniques use specialized templates:

Comparing to generate-and-validate techniques, template-based techniques tend to have better bug-fixing accuracy but a much narrowed scope. [6] [27]

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. [30] showed that the original fitness function of Genprog is not better than random search to drive the search. Long et al.'s [31] 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).

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. [32] "Overfitting" in this context refers to the fact that the patch overfits to the test inputs. There are different kinds of overfitting: 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. [6] reported that 104/110 of plausible GenProg patches were overfitting. In the context of synthesis-based repair, Le et al. [33] 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. [34] Alternatively, Tian et al. propose heuristic approaches to assess patch correctness. [35] [36]

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. [6] 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. [6] 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. [37]

A limitation of generate-and-validate repair systems is the search space explosion. [31] 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 [16] [17] 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. [13] [7] [12] [17]

In Java, the main benchmark is Defects4J now extensively used in most research papers on program repair for Java. [38] [39] Alternative benchmarks exist, such as the Quixbugs benchmark, [40] which contains original bugs for program repair. Other benchmarks of Java bugs include Bugs.jar, [41] based on past commits.

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

Related Research Articles

In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software, while preserving its functionality. Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

In the context of hardware and software systems, formal verification is the act of proving or disproving the correctness of a system with respect to a certain formal specification or property, using formal methods of mathematics. Formal verification is a key incentive for formal specification of systems, and is at the core of formal methods. It represents an important dimension of analysis and verification in electronic design automation and is one approach to software verification. The use of formal verification enables the highest Evaluation Assurance Level (EAL7) in the framework of common criteria for computer security certification.

Code review is a software quality assurance activity in which one or more people check a program, mainly by viewing and reading parts of its source code, either after implementation or as an interruption of implementation. At least one of the persons must not have authored the code. The persons performing the checking, excluding the author, are called "reviewers".

In programming and software development, fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks. Typically, fuzzers are used to test programs that take structured inputs. This structure is specified, e.g., in a file format or protocol and distinguishes valid from invalid input. An effective fuzzer generates semi-valid inputs that are "valid enough" in that they are not directly rejected by the parser, but do create unexpected behaviors deeper in the program and are "invalid enough" to expose corner cases that have not been properly dealt with.

Software visualization or software visualisation refers to the visualization of information of and related to software systems—either the architecture of its source code or metrics of their runtime behavior—and their development process by means of static, interactive or animated 2-D or 3-D visual representations of their structure, execution, behavior, and evolution.

A software regression is a type of software bug where a feature that has worked before stops working. This may happen after changes are applied to the software's source code, including the addition of new features and bug fixes. They may also be introduced by changes to the environment in which the software is running, such as system upgrades, system patching or a change to daylight saving time. A software performance regression is a situation where the software still functions correctly, but performs more slowly or uses more memory or resources than before. Various types of software regressions have been identified in practice, including the following:

Search-based software engineering (SBSE) applies metaheuristic search techniques such as genetic algorithms, simulated annealing and tabu search to software engineering problems. Many activities in software engineering can be stated as optimization problems. Optimization techniques of operations research such as linear programming or dynamic programming are often impractical for large scale software engineering problems because of their computational complexity or their assumptions on the problem structure. Researchers and practitioners use metaheuristic search techniques, which impose little assumptions on the problem structure, to find near-optimal or "good-enough" solutions.

In software engineering, software aging is the tendency for software to fail or cause a system failure after running continuously for a certain time, or because of ongoing changes in systems surrounding the software. Software aging has several causes, including the inability of old software to adapt to changing needs or changing technology platforms, and the tendency of software patches to introduce further errors. As the software gets older it becomes less well-suited to its purpose and will eventually stop functioning as it should. Rebooting or reinstalling the software can act as a short-term fix. A proactive fault management method to deal with the software aging incident is software rejuvenation. This method can be classified as an environment diversity technique that usually is implemented through software rejuvenation agents (SRA).

In computing, compiler correctness is the branch of computer science that deals with trying to show that a compiler behaves according to its language specification. Techniques include developing the compiler using formal methods and using rigorous testing on an existing compiler.

In computer programming and software development, debugging is the process of finding and resolving bugs within computer programs, software, or systems.

Extended static checking (ESC) is a collective name in computer science for a range of techniques for statically checking the correctness of various program constraints. ESC can be thought of as an extended form of type checking. As with type checking, ESC is performed automatically at compile time. This distinguishes it from more general approaches to the formal verification of software, which typically rely on human-generated proofs. Furthermore, it promotes practicality over soundness, in that it aims to dramatically reduce the number of false positives at the cost of introducing some false negatives. ESC can identify a range of errors that are currently outside the scope of a type checker, including division by zero, array out of bounds, integer overflow and null dereferences.

A software map represents static, dynamic, and evolutionary information of software systems and their software development processes by means of 2D or 3D map-oriented information visualization. It constitutes a fundamental concept and tool in software visualization, software analytics, and software diagnosis. Its primary applications include risk analysis for and monitoring of code quality, team activity, or software development progress and, generally, improving effectiveness of software engineering with respect to all related artifacts, processes, and stakeholders throughout the software engineering process and software maintenance.

Research and literature on concurrency testing and concurrent testing typically focuses on testing software and systems that use concurrent computing. The purpose is, as with most software testing, to understand the behaviour and performance of a software system that uses concurrent computing, particularly assessing the stability of a system or application during normal activity.

Software Intelligence is insight into the inner workings and structural condition of software assets produced by software designed to analyze database structure, software framework and source code to better understand and control complex software systems in Information Technology environments. Similarly to Business Intelligence (BI), Software Intelligence is produced by a set of software tools and techniques for the mining of data and the software's inner-structure. Results are automatically produced and feed a knowledge base containing technical documentation and blueprints of the innerworking of applications, and make it available to all to be used by business and software stakeholders to make informed decisions, measure the efficiency of software development organizations, communicate about the software health, prevent software catastrophes.

<span class="mw-page-title-main">American Fuzzy Lop (software)</span> Software fuzzer that employs genetic algorithms

American Fuzzy Lop (AFL), stylized in all lowercase as American fuzzy lop, is a free software fuzzer that employs genetic algorithms in order to efficiently increase code coverage of the test cases. So far it has detected dozens of significant software bugs in major free software projects, including X.Org Server, PHP, OpenSSL, pngcrush, bash, Firefox, BIND, Qt, and SQLite.

EvoSuite is a tool that automatically generates unit tests for Java software. EvoSuite uses an evolutionary algorithm to generate JUnit tests. EvoSuite can be run from the command line, and it also has plugins to integrate it in Maven, IntelliJ and Eclipse. EvoSuite has been used on more than a hundred open-source software and several industrial systems, finding thousands of potential bugs.

In computer software development, genetic Improvement is the use of optimisation and machine learning techniques, particularly search-based software engineering techniques such as genetic programming to improve existing software. The improved program need not behave identically to the original. For example, automatic bug fixing improves program code by reducing or eliminating buggy behaviour. In other cases the improved software should behave identically to the old version but is better because, for example: it runs faster, it uses less memory, it uses less energy or it runs on a different type of computer. GI differs from, for example, formal program translation, in that it primarily verifies the behaviour of the new mutant version by running both the new and the old software on test inputs and comparing their output and performance in order to see if the new software can still do what is wanted of the original program and is now better.

A software bot is a type of software agent in the service of software project management and software engineering. A software bot has an identity and potentially personified aspects in order to serve their stakeholders. Software bots often compose software services and provide an alternative user interface, which is sometimes, but not necessarily conversational.

Static application security testing (SAST) is used to secure software by reviewing the source code of the software to identify sources of vulnerabilities. Although the process of statically analyzing the source code has existed as long as computers have existed, the technique spread to security in the late 90s and the first public discussion of SQL injection in 1998 when Web applications integrated new technologies like JavaScript and Flash.

In computer science, a code property graph (CPG) is a computer program representation that captures syntactic structure, control flow, and data dependencies in a property graph. The concept was originally introduced to identify security vulnerabilities in C and C++ system code, but has since been employed to analyze web applications, cloud deployments, and smart contracts. Beyond vulnerability discovery, code property graphs find applications in code clone detection, attack-surface detection, exploit generation, measuring code testability, and backporting of security patches.

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. ↑ 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.
  4. ↑ 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.
  5. 1 2 3 4 5 6 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.
  6. 1 2 3 4 5 6 7 8 9 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.
  7. 1 2 3 4 5 6 7 8 9 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.
  8. 1 2 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.
  9. ↑ "Contract-based Data Structure Repair Using Alloy". CiteSeerX   10.1.1.182.4390 .{{cite journal}}: Cite journal requires |journal= (help)
  10. 1 2 3 4 5 6 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.
  11. ↑ 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.
  12. 1 2 3 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.
  13. 1 2 3 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.
  14. ↑ Qi, Zichao; Long, Fan; Achour, Sara; Rinard, Martin (2015-07-13). "An analysis of patch plausibility and correctness for generate-and-validate patch generation systems". Proceedings of the 2015 International Symposium on Software Testing and Analysis. New York, NY, USA: ACM. pp. 24–36. doi:10.1145/2771783.2771791. hdl:1721.1/101586. ISBN   9781450336208. S2CID   6845282.
  15. 1 2 3 4 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.
  16. 1 2 3 4 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.
  17. 1 2 3 4 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.
  18. ↑ 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.
  19. ↑ 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.
  20. ↑ 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.
  21. ↑ 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.
  22. 1 2 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.
  23. 1 2 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.
  24. 1 2 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. arXiv: 1902.06111 . doi: 10.1145/3360585 .
  25. ↑ 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.
  26. ↑ 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.
  27. 1 2 3 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.
  28. ↑ 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.
  29. 1 2 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.
  30. ↑ 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.
  31. 1 2 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.
  32. ↑ 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.
  33. ↑ 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.
  34. ↑ 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. pp. 226–236. doi:10.1145/3092703.3092718. ISBN   978-1-4503-5076-1. S2CID   20562134.
  35. ↑ Tian, Haoye; Liu, Kui; Kaboré, Abdoul Kader; Koyuncu, Anil; Li, Li; Klein, Jacques; Bissyandé, Tegawendé F. (27 January 2021). "Evaluating representation learning of code changes for predicting patch correctness in program repair". Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering. Association for Computing Machinery. pp. 981–992. doi:10.1145/3324884.3416532. ISBN   9781450367684.
  36. ↑ Tian, Haoye; Tang, Xunzhu; Habib, Andrew; Wang, Shangwen; Liu, Kui; Xia, Xin; Klein, Jacques; BissyandÉ, TegawendÉ F. (5 January 2023). "Is this Change the Answer to that Problem?: Correlating Descriptions of Bug and Code Changes for Evaluating Patch Correctness". Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering. Association for Computing Machinery. pp. 1–13. arXiv: 2208.04125 . doi:10.1145/3551349.3556914. ISBN   9781450394758. S2CID   251403079.
  37. 1 2 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.
  38. ↑ 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. New York, New York, USA: ACM Press. pp. 1–11. doi:10.1145/3180155.3180233. ISBN   9781450356381. S2CID   3374770.
  39. ↑ 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. New York, New York, USA: ACM Press. pp. 12–23. doi: 10.1145/3180155.3180245 . ISBN   9781450356381. S2CID   49666327.
  40. ↑ 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. New York, New York, USA: ACM Press. pp. 55–56. doi: 10.1145/3135932.3135941 . ISBN   9781450355148.
  41. ↑ Saha, Ripon K.; Lyu, Yingjun; Lam, Wing; Yoshida, Hiroaki; Prasad, Mukul R. (2018). "Bugs.jar". Proceedings of the 15th International Conference on Mining Software Repositories. MSR '18. pp. 10–13. doi:10.1145/3196398.3196473. ISBN   9781450357166. S2CID   50770093.
  42. ↑ 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 .
  43. ↑ 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.
  44. ↑ 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.
  45. ↑ "AI is coming for your coding job". Sifted. 13 March 2019. Retrieved 2019-04-15.
  46. ↑ "Ishraq Khan, Revolutionizing the Programming Scene in 2021". TechTimes. 13 September 2019. Retrieved 2022-10-15.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.