Automatic bug fixing: Difference between revisions

Revision as of 08:35, 24 April 2025

Revision as of 08:43, 22 June 2025

Line 6:

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]].<ref name="genprog2009">{{Cite book |last1=Weimer |first1=Westley |title=Proceedings of the 31st International Conference on Software Engineering |last2=Nguyen |first2=ThanhVu |last3=Le Goues |first3=Claire|author3-link=Claire Le Goues |last4=Forrest |first4=Stephanie |date=2009 |publisher=IEEE |isbn=978-1-4244-3453-4 |pages=364–374 |chapter=Automatically finding patches using genetic programming |citeseerx=10.1.1.147.8995 |doi=10.1109/ICSE.2009.5070536 |s2cid=1706697}}</ref>

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 |last1=Qi |first1=Zichao |title=Proceedings of the 2015 International Symposium on Software Testing and Analysis |last2=Long |first2=Fan |last3=Achour |first3=Sara |last4=Rinard |first4=Martin |date=2015 |publisher=ACM |isbn=978-1-4503-3620-8 |chapter=An AnlysisAnalysis 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 |last1=Long |first1=Fan |title=Proceedings of the 43rd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages |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 |bibcode=2014arXiv1403.1117P |doi=10.1109/TSE.2014.2312918 |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" />