23 research outputs found
Program Repair by Stepwise Correctness Enhancement
Relative correctness is the property of a program to be more-correct than
another with respect to a given specification. Whereas the traditional
definition of (absolute) correctness divides candidate program into two classes
(correct, and incorrect), relative correctness arranges candidate programs on
the richer structure of a partial ordering. In other venues we discuss the
impact of relative correctness on program derivation, and on program
verification. In this paper, we discuss the impact of relative correctness on
program testing; specifically, we argue that when we remove a fault from a
program, we ought to test the new program for relative correctness over the old
program, rather than for absolute correctness. We present analytical arguments
to support our position, as well as an empirical argument in the form of a
small program whose faults are removed in a stepwise manner as its relative
correctness rises with each fault removal until we obtain a correct program.Comment: In Proceedings PrePost 2016, arXiv:1605.0809
Tortoise: Interactive System Configuration Repair
System configuration languages provide powerful abstractions that simplify
managing large-scale, networked systems. Thousands of organizations now use
configuration languages, such as Puppet. However, specifications written in
configuration languages can have bugs and the shell remains the simplest way to
debug a misconfigured system. Unfortunately, it is unsafe to use the shell to
fix problems when a system configuration language is in use: a fix applied from
the shell may cause the system to drift from the state specified by the
configuration language. Thus, despite their advantages, configuration languages
force system administrators to give up the simplicity and familiarity of the
shell.
This paper presents a synthesis-based technique that allows administrators to
use configuration languages and the shell in harmony. Administrators can fix
errors using the shell and the technique automatically repairs the higher-level
specification written in the configuration language. The approach (1) produces
repairs that are consistent with the fix made using the shell; (2) produces
repairs that are maintainable by minimizing edits made to the original
specification; (3) ranks and presents multiple repairs when relevant; and (4)
supports all shells the administrator may wish to use. We implement our
technique for Puppet, a widely used system configuration language, and evaluate
it on a suite of benchmarks under 42 repair scenarios. The top-ranked repair is
selected by humans 76% of the time and the human-equivalent repair is ranked
1.31 on average.Comment: Published version in proceedings of IEEE/ACM International Conference
on Automated Software Engineering (ASE) 201
MintHint: Automated Synthesis of Repair Hints
Being able to automatically repair programs is an extremely challenging task.
In this paper, we present MintHint, a novel technique for program repair that
is a departure from most of today's approaches. Instead of trying to fully
automate program repair, which is often an unachievable goal, MintHint performs
statistical correlation analysis to identify expressions that are likely to
occur in the repaired code and generates, using pattern-matching based
synthesis, repair hints from these expressions. Intuitively, these hints
suggest how to rectify a faulty statement and help developers find a complete,
actual repair. MintHint can address a variety of common faults, including
incorrect, spurious, and missing expressions.
We present a user study that shows that developers' productivity can improve
manyfold with the use of repair hints generated by MintHint -- compared to
having only traditional fault localization information. We also apply MintHint
to several faults of a widely used Unix utility program to further assess the
effectiveness of the approach. Our results show that MintHint performs well
even in situations where (1) the repair space searched does not contain the
exact repair, and (2) the operational specification obtained from the test
cases for repair is incomplete or even imprecise
Connecting Program Synthesis and Reachability: Automatic Program Repair using Test-Input Generation
We prove that certain formulations of program synthesis and reachability are equivalent. Specifically, our constructive proof shows the reductions between the template-based synthesis problem, which generates a program in a pre-specified form, and the reachability problem, which decides the reachability of a program location. This establishes a link between the two research fields and allows for the transfer of techniques and results between them.
To demonstrate the equivalence, we develop a program repair prototype using reachability tools. We transform a buggy program and its required specification into a specific program containing a location reachable only when the original program can be repaired, and then apply an off-the-shelf test-input generation tool on the transformed program to find test values to reach the desired location. Those test values correspond to repairs for the original program. Preliminary results suggest that our approach compares favorably to other repair methods
Automated Fixing of Programs with Contracts
This paper describes AutoFix, an automatic debugging technique that can fix
faults in general-purpose software. To provide high-quality fix suggestions and
to enable automation of the whole debugging process, AutoFix relies on the
presence of simple specification elements in the form of contracts (such as
pre- and postconditions). Using contracts enhances the precision of dynamic
analysis techniques for fault detection and localization, and for validating
fixes. The only required user input to the AutoFix supporting tool is then a
faulty program annotated with contracts; the tool produces a collection of
validated fixes for the fault ranked according to an estimate of their
suitability.
In an extensive experimental evaluation, we applied AutoFix to over 200
faults in four code bases of different maturity and quality (of implementation
and of contracts). AutoFix successfully fixed 42% of the faults, producing, in
the majority of cases, corrections of quality comparable to those competent
programmers would write; the used computational resources were modest, with an
average time per fix below 20 minutes on commodity hardware. These figures
compare favorably to the state of the art in automated program fixing, and
demonstrate that the AutoFix approach is successfully applicable to reduce the
debugging burden in real-world scenarios.Comment: Minor changes after proofreadin