Practical program repair via bytecode mutation

Abstract

Software debugging is tedious, time-consuming, and even errorprone by itself. So, various automated debugging techniques have been proposed in the literature to facilitate the debugging process. Automated Program Repair (APR) is one of the most recent advances in automated debugging, and can directly produce patches for buggy programs with minimal human intervention. Although various advanced APR techniques (including those that are either search-based or semantic-based) have been proposed, the simplistic mutation-based APR technique, which simply uses pre-defined mutation operators (e.g., changing a>=b into a>b) to mutate programs for finding patches, has not yet been thoroughly studied. In this paper, we implement the first practical bytecode-level APR technique, PraPR, and present the first extensive study on fixing real-world bugs (e.g., Defects4J bugs) using bytecode mutation. The experimental results show that surprisingly even PraPR with only the basic traditional mutators can produce genuine patches for 18 bugs. Furthermore, with our augmented mutators, PraPR is able to produce genuine patches for 43 bugs, significantly outperforming state-of-the-art APR. It is also an order of magnitude faster, indicating a promising future for bytecode-mutation-based APR.

iFixFlakies: a framework for automatically fixing order-dependent flaky tests

“…Note that iFixFlakies performance can be improved, e.g., Patcher could modify the bytecode of the patch code in-memory [23,35] to avoid compilation during delta debugging, or could instrument the code to allow turning statements on or off during delta debugging similar to metamutants [31,50]. In general, considering the large amount of time to create all patches and there being fewer unique patches than all patches, we do not recommend developers to use iFixFlakies to create all patches using all helpers for each orderdependent test; obtaining just a few appears to suffice.…”

TBar: revisiting template-based automated program repair

“…If the patched program passes all tests successfully, the patch candidate is considered as a plausible patch [58]. Once such a plausible patch is identified, TBar stops generating other patch candidates for this bug to fix bugs in a standard and practical program repair workflow [38,39,49,76,77], but does not generate all plausible patches for each bug, unlike PraPR [15]. Otherwise, the pattern selection and patch generation process is resumed until all AST nodes of buggy code are traversed.…”

“…Request permissions from permissions@acm.org. ISSTA '19, July [15][16][17][18][19]2019 18,21,23,25,26,29,31,36,38,39,41,42,44,51,53,67,69,76,77] have been proposed, aiming at reducing manual debugging efforts through automatically generating patches.…”

“…Recently, Liu et al [39] used the fix patterns of FindBugs static violations [35] to fix semantic bugs. Concurrently, Ghanbari and Zhang [15] showed that straightforward application of fix patterns (i.e., mutators) on Java bytecode is effective for repair. They do not, however, provide a comprehensive assessment of the repair performance yielded by each implemented mutator.…”

PRF: a framework for building automatic program repair prototypes for JVM-based languages

“…Mehne et al [15] report that patch validation can take between 40% to 92% of total repair time and propose to prune the patches needed to be tested as well as test case selection to reduce this cost. A recent line of research [6,9], proposes to use the HotSwap trick offered by the JVM to validate the patches on-the-fly, without restarting the JVM. This was previously used in mutation testing systems like PIT [2].…”