Content deleted Content added
No edit summary Tags: Reverted Mobile edit Mobile web edit |
Jnestorius (talk | contribs) |
||
| (4 intermediate revisions by 4 users not shown) | |||
Line 1:
{{short description|Automatic repair of software bugs}}
'''Automatic bug-fixing''' is the automatic [[Patch (computing)|repair]] of [[software bug]]s without the intervention of a human programmer.<ref>{{Cite journal |last=Rinard |first=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 |last=Harman |first=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><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 |url=https://boa.unimib.it/bitstream/10281/184798/2/08089448_final.pdf |journal=IEEE Transactions on Software Engineering |volume=45 |issue=1 |pages=34–67 |doi=10.1109/TSE.2017.2755013 |hdl=10281/184798 |s2cid=57764123|doi-access=free }}</ref> It is also commonly referred to as ''automatic patch generation'', ''automatic bug repair'', or ''automatic program repair''.<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 |url=https://boa.unimib.it/bitstream/10281/184798/2/08089448_final.pdf |journal=IEEE Transactions on Software Engineering |volume=45 |issue=1 |pages=34–67 |doi=10.1109/TSE.2017.2755013 |hdl=10281/184798 |s2cid=57764123|doi-access=free }}</ref> The typical goal of such techniques is to automatically generate correct [[Patch (computing)|patches]] to eliminate bugs in [[software program]]s without causing [[software regression]].<ref>{{Cite book |last1=Tan |first1=Shin Hwei |title=2015 IEEE/ACM 37th IEEE International Conference on Software Engineering |last2=Roychoudhury |first2=Abhik |date=2015 |publisher=IEEE |isbn=978-1-4799-1934-5 |pages=471–482 |chapter=relifix: Automated repair of software regressions |doi=10.1109/ICSE.2015.65 |s2cid=17125466}}</ref>
Line 200 ⟶ 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
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" />
Line 208 ⟶ 14:
=== 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
<!-- mutation based repair -->
Line 258 ⟶ 64:
One way to avoid overfitting is to filter out the generated patches. This can be done based on dynamic analysis.<ref>{{Cite book|last1=Xin|first1=Qi|last2=Reiss|first2=Steven P.|title=Proceedings of the 26th ACM SIGSOFT International Symposium on Software Testing and Analysis |chapter=Identifying test-suite-overfitted patches through test case generation |date=2017-07-10|chapter-url=http://dx.doi.org/10.1145/3092703.3092718|pages=226–236|___location=New York, NY, USA|publisher=ACM|doi=10.1145/3092703.3092718|isbn=978-1-4503-5076-1|s2cid=20562134}}</ref>
Alternatively, Tian et al. propose heuristic approaches to assess patch correctness.
== Limitations of automatic bug-fixing ==
Line 273 ⟶ 79:
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.<ref name=genprog2012 /><ref name=prophet /><ref name=spr /><ref name=angelix />
In [[Java (programming language)|Java]], the main benchmark is Defects4J now extensively used in most research papers on program repair for Java.<ref name="capgen">{{Cite book |last1=Wen |first1=Ming |last2=Chen |first2=Junjie |last3=Wu |first3=Rongxin |last4=Hao |first4=Dan |last5=Cheung |first5=Shing-Chi |title=Proceedings of the 40th International Conference on Software Engineering |chapter=Context-aware patch generation for better automated program repair |date=2018 |___location=New York, New York, USA |publisher=ACM Press |pages=1–11 |doi=10.1145/3180155.3180233 |isbn=9781450356381 |s2cid=3374770|url=https://repository.hkust.edu.hk/ir/Record/1783.1-92186 |chapter-url=
== Example tools ==
Line 314 ⟶ 120:
== External links ==
* {{URL|
[[Category:Debugging]]
| |||