Automatic bug fixing: Difference between revisions

Content deleted Content added
Citation bot (talk | contribs)
Alter: url, pages. URLs might have been anonymized. Add: date, s2cid, isbn, hdl, pages, authors 1-1. Removed parameters. Formatted dashes. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Abductive | #UCB_webform 2036/3849
Line 17:
 
<!-- mutation based repair -->
One way to generate candidate patches is to apply [[program mutation|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 (programming)|statement]]-level or [[Block (programming)|block]]-level. Earlier [[Genetic improvement (computer science)|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.<ref name=genprog2009 /><ref name="genprog2012">{{Cite book |last1=Le Goues |first1=Claire |title=2012 34th International Conference on Software Engineering (ICSE) |last2=Dewey-Vogt |first2=Michael |last3=Forrest |first3=Stephanie |last4=Weimer |first4=Westley |date=2012 |publisher=IEEE |isbn=978-1-4673-1067-3 |pages=3–13 |chapter=A Systematic Study of Automated Program Repair: Fixing 55 out of 105 Bugs for $8 Each |citeseerx=10.1.1.661.9690 |doi=10.1109/ICSE.2012.6227211 |s2cid=10987936}}</ref> Recent approaches use more fine-grained operators at the [[abstract syntax tree]] level to generate more diverse set of candidate patches.<ref name=spr /> Notably, the statement deletion mutation operator, and more generally removing code, is a reasonable repair strategy, or at least a good fault localization strategy.<ref>{{Cite journal |lastlast1=Qi |firstfirst1=Zichao |last2=Long |first2=Fan |last3=Achour |first3=Sara |last4=Rinard |first4=Martin |date=2015-07-13 |title=An analysis of patch plausibility and correctness for generate-and-validate patch generation systems |url=http://dx.doi.org/10.1145/2771783.2771791 |journal=Proceedings of the 2015 International Symposium on Software Testing and Analysis |pages=24–36 |___location=New York, NY, USA |publisher=ACM |doi=10.1145/2771783.2771791|hdl=1721.1/101586 |isbn=9781450336208 |s2cid=6845282 }}</ref><ref>{{Cite journal |lastlast1=Ginelli |firstfirst1=Davide |last2=Martinez |first2=Matias |last3=Mariani |first3=Leonardo |last4=Monperrus |first4=Martin |date=2022 |title=A comprehensive study of code-removal patches in automated program repair |url=https://link.springer.com/10.1007/s10664-021-10100-7 |journal=Empirical Software Engineering |language=en |volume=27 |issue=4 |pages=97 |doi=10.1007/s10664-021-10100-7 |s2cid=228376263 |issn=1382-3256}}</ref>
 
<!-- fix templates -->
Line 53:
* In a continuous integration server: When a build fails during continuous integration, a patch search can be attempted as soon as the build has failed. If the search is successful, the patch is provided to the developer.<ref>{{Cite book |last1=Urli |first1=Simon |title=How to design a program repair bot?: insights from the repairnator project |last2=Yu |first2=Zhongxing |last3=Seinturier |first3=Lionel |last4=Monperrus |first4=Martin |date=27 May 2018 |isbn=9781450356596 |pages=95–104 |chapter=How to design a program repair bot? |arxiv=1811.09852 |doi=10.1145/3183519.3183540 |chapter-url=https://hal.archives-ouvertes.fr/hal-01691496/document |s2cid=49237449}}</ref> When a synthesized patch is suggested to the developers as pull-request, an explanation has to be provided in addition to the code changes (e.g. a pull request title and description).<ref>{{Cite book |last=Monperrus |first=Martin |title=2019 IEEE/ACM 1st International Workshop on Bots in Software Engineering (BotSE) |year=2019 |isbn=978-1-7281-2262-5 |pages=12–15 |chapter=Explainable Software Bot Contributions: Case Study of Automated Bug Fixes |arxiv=1905.02597 |bibcode=2019arXiv190502597M |doi=10.1109/BotSE.2019.00010 |s2cid=146808763}}</ref> An experiment has shown that generated patches can be accepted by open-source developers and merged in the code repository.<ref>{{Cite journal |last1=Monperrus |first1=Martin |last2=Urli |first2=Simon |last3=Durieux |first3=Thomas |last4=Martinez |first4=Matias |last5=Baudry |first5=Benoit |last6=Seinturier |first6=Lionel |date=2019 |title=Repairnator patches programs automatically |url=https://hal.archives-ouvertes.fr/hal-02267512/document |journal=Ubiquity |volume=2019 |issue=July |pages=1–12 |arxiv=1910.06247 |bibcode=2019arXiv191006247M |doi=10.1145/3349589 |s2cid=198986312}}</ref>
* At runtime: When a failure happens at runtime, a binary patch can be searched for and [[Self-modifying code|applied online]]. An example of such a repair system is ClearView,<ref name="clearview">{{Cite book |last=Perkins |first=Jeff H. |title=Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles |date=2009 |publisher=ACM |isbn=978-1-60558-752-3 |pages=87–102 |chapter=Automatically patching errors in deployed software |citeseerx=10.1.1.157.5877 |doi=10.1145/1629575.1629585 |display-authors=etal |s2cid=7597529}}</ref> which does repair on x86 code, with x86 binary patches. The Itzal system<ref>{{Cite book |last1=Durieux |first1=Thomas |title=2017 IEEE/ACM 39th International Conference on Software Engineering: New Ideas and Emerging Technologies Results Track (ICSE-NIER) |last2=Hamadi |first2=Youssef |last3=Monperrus |first3=Martin |year=2017 |isbn=978-1-5386-2675-7 |pages=23–26 |chapter=Production-driven patch generation |arxiv=1812.04475 |doi=10.1109/icse-nier.2017.8 |chapter-url=https://hal.archives-ouvertes.fr/hal-01463689/document |s2cid=7737476}}</ref> is different from Clearview: while the repair search happens at runtime, in production, the produced patches are at the source code level. The BikiniProxy system does online repair of JavaScript errors happening in the browser.<ref>{{Cite book |last1=Durieux |first1=Thomas |title=2018 IEEE 29th International Symposium on Software Reliability Engineering (ISSRE) |last2=Hamadi |first2=Youssef |last3=Monperrus |first3=Martin |year=2018 |isbn=978-1-5386-8321-7 |pages=1–12 |chapter=Fully Automated HTML and Javascript Rewriting for Constructing a Self-Healing Web Proxy |arxiv=1803.08725 |bibcode=2018arXiv180308725D |doi=10.1109/ISSRE.2018.00012 |s2cid=4268784}}</ref>
* In response to security disclosures: when vulnerabilities are discovered and registered as CVEs, one can ask a repair system to generate a security patch.<ref>{{Cite journal |lastlast1=Chen |firstfirst1=Zimin |last2=Kommrusch |first2=Steve James |last3=Monperrus |first3=Martin |date=2022 |title=Neural Transfer Learning for Repairing Security Vulnerabilities in C Code |url=https://ieeexplore.ieee.org/document/9699412/ |journal=IEEE Transactions on Software Engineering |pages=1–11 |doi=10.1109/TSE.2022.3147265 |s2cid=233296471 |issn=0098-5589}}</ref>
 
== Search space ==
Line 61:
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 |date=2019 |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 |arxiv=1802.03365 |doi=10.1016/j.jss.2019.01.069 |s2cid=3619320}}</ref> 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.<ref name="Martinez2019" />
 
It is also possible to analyze whether known search spaces encompass existing commits.<ref>{{Cite journal|lastlast1=Etemadi|firstfirst1=Khashayar|last2=Tarighat|first2=Niloofar|last3=Yadav|first3=Siddharth|last4=Martinez|first4=Matias|last5=Monperrus|first5=Martin|date=2022|title=Estimating the potential of program repair search spaces with commit analysis|url=https://linkinghub.elsevier.com/retrieve/pii/S0164121222000309|journal=Journal of Systems and Software|language=en|volume=188|pages=111263|doi=10.1016/j.jss.2022.111263|s2cid=246485882 }}</ref> Such a search space analysis means [[Mining software repositories|mining a software repository]], this results in an approximation of the applicability and usefulness of a given repair algorithm.
 
== Overfitting ==
Line 116:
=== Proprietary ===
 
* DeepCode integrates public and private [[GitHub]], [[GitLab]] and [[Bitbucket]] [[Software repository|repositories]] to identify code-fixes and improve software.<ref>{{Cite web |title=AI is coming for your coding job |url=https://sifted.eu/articles/ai-is-coming-for-your-coding-job/ |access-date=2019-04-15 |website=Sifted |date=13 March 2019 |language=en-US}}</ref>
 
== References ==