Content deleted Content added
Citation bot (talk | contribs) Add: isbn, s2cid. | Use this bot. Report bugs. | #UCB_CommandLine 711/10111 |
Citation bot (talk | contribs) Alter: title, template type, url. URLs might have been anonymized. Add: chapter-url, chapter. Removed or converted URL. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox3 | #UCB_webform_linked 187/2306 |
||
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
<!-- fix templates -->
Line 63:
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.<ref name="overfitting">{{Cite book |last1=Smith |first1=Edward K. |title=Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering |last2=Barr |first2=Earl T. |last3=Le Goues |first3=Claire |last4=Brun |first4=Yuriy |date=2015 |publisher=ACM |isbn=978-1-4503-3675-8 |series=ESEC/FSE 2015 |___location=New York, New York |pages=532–543 |chapter=Is the Cure Worse Than the Disease? Overfitting in Automated Program Repair |doi=10.1145/2786805.2786825 |s2cid=6300790}}</ref> "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.<ref name="kali" /> reported that 104/110 of plausible GenProg patches were overfitting. In the context of synthesis-based repair, Le et al.<ref>{{Cite journal |last1=Le |first1=Xuan Bach D. |last2=Thung |first2=Ferdian |last3=Lo |first3=David |last4=Goues |first4=Claire Le |date=2018-03-02 |title=Overfitting in semantics-based automated program repair |url=https://ink.library.smu.edu.sg/sis_research/3986 |journal=Empirical Software Engineering |language=en |volume=23 |issue=5 |pages=3007–3033 |doi=10.1007/s10664-017-9577-2 |issn=1382-3256 |s2cid=3635768}}</ref> 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.<ref>{{Cite
Alternatively, Tian et al. propose heuristic approaches to assess patch correctness. <ref>{{cite news |last1=Tian |first1=Haoye |last2=Liu |first2=Kui |last3=Kaboré |first3=Abdoul Kader |last4=Koyuncu |first4=Anil |last5=Li |first5=Li |last6=Klein |first6=Jacques |last7=Bissyandé |first7=Tegawendé F. |title=Evaluating representation learning of code changes for predicting patch correctness in program repair |url=https://dl.acm.org/doi/abs/10.1145/3324884.3416532 |work=Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering |publisher=Association for Computing Machinery |date=27 January 2021 |pages=981–992 |doi=10.1145/3324884.3416532|isbn=9781450367684 }}</ref><ref>{{cite journal |last1=Tian |first1=Haoye |last2=Tang |first2=Xunzhu |last3=Habib |first3=Andrew |last4=Wang |first4=Shangwen |last5=Liu |first5=Kui |last6=Xia |first6=Xin |last7=Klein |first7=Jacques |last8=BissyandÉ |first8=TegawendÉ F. |title=Is this Change the Answer to that Problem? Correlating Descriptions of Bug and Code Changes for Evaluating Patch Correctness |journal=Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering |date=5 January 2023 |pages=1–13 |doi=10.1145/3551349.3556914 |url=https://dl.acm.org/doi/abs/10.1145/3551349.3556914 |publisher=Association for Computing Machinery|s2cid=251403079 }}</ref>
Line 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, the main benchmark is Defects4J now extensively used in most research papers on program repair for Java.<ref name="capgen">{{Cite
== Example tools ==
| |||