Multi-Location Program Repair Strategies Learned from Past Successful Experience
Automated program repair (APR) has great potential to reduce the effort and time-consumption in software maintenance and becomes a hot topic in software engineering recently with many approaches being proposed. Multi-location program repair has always been a challenge in this field since its complexity in logic and structure. While some approaches do not claim to have the features for solving multi-location bugs, they generate correct patches for these defects in practice. In this paper, we first make an observation on multi-location bugs in Defects4J and divide them into two categories (i.e., similar and relevant multi-location bugs) based on the repair actions in their patches. We then summarize the situation of multi-location bugs in Defects4J fixed by current tools. We analyze the twenty-two patches generated by current tools and propose two feasible strategies for fixing multi-location bugs, illustrating them through two detailed case studies. At last, the experimental results prove the feasibility of our methods with the repair of two bugs that have never been fixed before. By learning from successful experience in the past, this paper points out possible ways ahead for multi-location program repair.
💡 Research Summary
The paper tackles the long‑standing challenge of repairing multi‑location bugs in automated program repair (APR). By exhaustively examining the Defects4J benchmark, the authors first categorize multi‑location defects into two distinct groups based on the repair actions observed in existing patches. “Similar” bugs require the same kind of edit (e.g., condition replacement, method‑call insertion) to be applied at several independent locations, whereas “relevant” bugs involve edits that are logically interdependent across different sites. This taxonomy provides a clear lens through which to assess the capabilities of current APR tools.
The study then surveys 22 patches produced by state‑of‑the‑art APR systems such as jGenProg, Nopol, and Prophet. Although most tools do not explicitly claim multi‑location support, a non‑trivial number of patches nevertheless succeed, and they tend to fall neatly into the two categories defined above. Careful inspection of these successful cases leads the authors to formulate two concrete repair strategies.
The first strategy targets “similar” bugs by allowing a single transformation to be instantiated simultaneously at multiple program points. To realize this, the authors augment the transformation‑generation phase with location‑agnostic candidates and modify the search algorithm to permit combinatorial application of identical edits across different sites. The second strategy addresses “relevant” bugs by modeling dependencies between edits as a graph. A dependency‑aware search then selects a set of mutually supporting transformations, ensuring that the combined patch restores the overall program logic. Both strategies are designed as lightweight extensions to existing APR pipelines, avoiding exponential blow‑up of the search space while expanding coverage to multi‑location scenarios.
To validate the proposals, the authors integrate the strategies into existing tools and evaluate them on two previously unsolved Defects4J bugs (Lang‑57 and Math‑73). In both cases the system automatically generates correct patches, demonstrating that the lack of explicit multi‑location handling in current APR tools can be overcome by the introduced techniques.
The paper concludes by outlining future research directions: generalizing the strategies across a broader set of APR frameworks, incorporating machine‑learning heuristics to prioritize promising edit combinations, extending experiments to other bug repositories (e.g., Bugs.jar, QuixBugs), and developing quantitative metrics for multi‑location bug difficulty. Overall, the work provides a systematic classification of multi‑location defects, extracts actionable lessons from past successes, and proposes concrete, empirically validated methods that advance the state of automated program repair.
Comments & Academic Discussion
Loading comments...
Leave a Comment