Automatic bug fixing: Difference between revisions

Revision as of 22:22, 29 September 2016

Revision as of 22:44, 29 September 2016

Line 6:

'''Automatic bug-fixing''' is the automatic [[Patch (computing)|repair]] of [[software bug]]s without the intervention of a human programmer

<ref>Patching program errors (CACM 2008) {{DOI|10.1145/1409360.1409381}}</ref> <ref>Automated Patching Techniques: The Fix Is In (CACM 2010) {{DOI|10.1145/1735223.1735248}}</ref>. It is also commonly referred to as ''automatic patch generation'', ''automatic bug repair'', or ''automatic program repair''. The typical goal of such techniques is to automatically generate a correct [[Patch (computing) |patch]] to eliminate a [[software bug | bug]] in a software program without causing [[software regression]].

Techniques for automatic bug-fixing are still in their infancy, but are broadly divided into two camps depending on the way the proposed repair or patch is evaluated: those based on [[Formal verification|formal analysis]], and those that use a generate-and-validate [[search-based software engineering | search-based]] approach. The former relies on the availability of [[formal specification]] of the correct behavior of a program, anduses generates[[program synthesis]] techniques to synthesize a repairpatch, and then verifies the patched program satisfying the specification, whilst; the latter relies on the availability of a [[test suite]] or similar artifact, andgenerates a search space of candidate patches, uses [[automated testing]] techniques to validate theeach outcomecandidate ofpatch one by one, and collects validated patches that pass the repairtest processsuite.

==Techniques using formal verification==

Verification-based program repair combines techniques from [[formal verification]], [[program synthesis]], and fault-localisationlocalization. Industrial application of these techniques is limited due to the computation cost involved; it is not clear how potentially scalable such methods are. To reduce the number of possible repairs and hence the computational cost, often only a small pre-defined class of bugs is considered. Examples of bug classes include off-by-one errors and memory leaks

.<ref>Automatic Software Repair http://www.monperrus.net/martin/automatic-software-repair</ref>

==TestGenerate-and-validate techniques==

In Testgenerate-and-Validatevalidate approaches, program repair is performed with respect to an [[Oracle (software testing)|oracle]], encompassing the desired functionality of the program, which is used for validation of the generated fix. A simple example is a test-suite - the input/output pairs specify the functionality of the program, possibly captured in [[Assertion (software development)|assertions]]. This oracle can in fact be divided between the ''bug oracle'' that detects faulty behaviourbehavior, and the ''regression oracle'', which encapsulates the functionality any program repair method must preserve.

A variety of tools are employed to generate a candidate repair, typically either deterministic approaches using solvers for [[satisfiability modulo theories]] (SMT)