Contract-Based Program Repair Without The Contracts: An Extended Study

Abstract

Most techniques for automated program repair (APR) use tests to drive the repair process; this makes them prone to generating spurious repairs that overfit the available tests unless additional information about expected program behavior is available. Our previous work on JAID, an APR technique for Java programs, showed that constructing detailed state abstractions-similar to those employed by techniques for programs with contracts-from plain Java code without any special annotations provides valuable additional information, and hence helps mitigate the overfitting problem. This paper extends the work on JAID with a comprehensive experimental evaluation involving 693 bugs in three different benchmark suites. The evaluation shows, among other things, that: 1) JAID is effective: it produced correct fixes for over 15% of all bugs, with a precision of nearly 60%; 2) JAID is reasonably efficient: on average, it took less than 30 minutes to output a correct fix; 3) JAID is competitive with the state of the art, as it fixed more bugs than any other technique, and 11 bugs that no other tool can fix; 4) JAID is robust: its heuristics are complementary and their effectiveness does not depend on the fine-tuning of parameters. The experimental results also indicate the main trade-offs involved in designing an APR technique based on tests, as well as possible directions for further progress in this line of work.

Automated Program Repair from Fuzzing Perspective

“…In this paper, we will assume an APR approach that includes a patch ranking step where valid patches collected are ranked before being presented to the user. This approach is in line with recent works [10,11,15,16,26,43,60,62,70]. In the first part of this paper, we will describe in more detail the relationship between fuzzing and APR.…”

How do Developers Really Feel About Bug Fixing? Directions for Automatic Program Repair

“…APR research should consider the benefits of providing multiple fixes to a single bug: Our survey respondents had a strong preference for choosing between multiple fixes. There is some APR research that takes this approach (for example, [57], [58], [59]) -our results suggest that this may be a promising future direction, although more work is needed to identify what the ideal number of fixes for developers to choose from is.…”

Neural Program Repair: Systems, Challenges and Solutions

“…important research topic in both software engineering and artificial intelligence community. In the last decade, the most of the popular APR approaches are test-suite-based ones [7,14,17,26,27,32,45,47,48,50], where test cases of the buggy program are adopted as specifications to guide the repair process. During the bug-fixing, candidate patches are continuously generated to be applied on the buggy program until the patched program meets the expected behaviour described by the specification.…”