Pith. sign in

REVIEW 4 major objections 5 minor 80 references

CausalRepair: Bridging the Causality Gap in Large Language Model-Based Automated Program Repair via Dual-Slicing

T0 review · 4 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A minimal causal context—a purified failing test plus the executed statements behind the failed assertion—fixes 313 Defects4J bugs on DeepSeek-V3.

desk verdict Genuinely new context-construction idea, but the prompt template appears to leak the exact buggy line; the 313-bug headline needs that resolved before it is credible. read the letter →

arxiv 2608.10613 v1 pith:LB7ZVAQ3 submitted 2026-08-11 cs.SE

Linhao Wu , Yizhou Chen , Zhen Yang , Pengyu Xue , Dan Hao This is my paper · ORCID
classification cs.SE
keywords AutomatedProgramRepairLargeLanguageModelsSlicingDynamicStaticCausalContextDefects4JConversation-Driven
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that large language models fail at automated program repair not because they lack context but because the context is the wrong kind: full tests bury the failing assertion in unrelated scenarios, and static source retrieval includes code that never runs. It proposes a minimal causal context, defined as the essential set of dependencies required to explain a specific failure, and builds it by two slicing passes: a static backward slice of the failing test that keeps only the assertion and its setup, and a dynamic backward slice of the executed trace that keeps only the statements that influenced the failed assertion. On Defects4J V1.2 and V2.0 with DeepSeek-V3, this approach correctly fixes 313 bugs, 77 more than the best reproduced baseline, at an average cost of $0.029 per fixed bug. The paper's point is that causal relevance, not context size, is what lets an LLM repair code.

What carries the argument

The load-bearing object is the minimal causal context, instantiated by dual-slicing. On the test side, context-aware static slicing builds a System Dependence Graph and takes the transitive closure of data and control dependence from the failing assertion ($\kappa = \langle s_{fail}, V_{fail}\rangle$) to obtain $S_{intra}$, then resolves inter-procedural dependencies for called methods and referenced fields. On the source side, execution-trace-based dynamic slicing maps the failing line to its last runtime event and computes backward dependence over a Dynamic Dependence Graph of the execution trace, yielding $S_{dyn}$. An AST-based reconstruction step re-embeds the fragmented statements into class and method skeletons and injects semantic anchors, so the final prompt is structurally coherent rather than a list of lines. This machinery does the filtering work: it removes unexecuted code and unrelated assertions while preserving the chain from a state-mutating test action to the failed assertion.

What would settle it

Construct or select a bug whose root cause is a missing action, such as a deleted null-check or an uninitialized field, so the failure is caused by an absent statement rather than an executed one, and check whether CausalRepair fixes it while a baseline given the full method can; a failure here would show the dynamic slice omits the causal fact. A more direct check is to instrument the slicer and record, for each of the 313 claimed fixes, whether the developer patch's changed lines fall inside the dynamic slice; any fixed bug whose changed lines lie outside the slice would contradict the claim that the slice carries the causal context.

Watch

Extended reading notes

Core claim

The central claim is that a repair prompt built from the intersection of test semantics and actual runtime causality lets an LLM identify root causes it otherwise misses. CausalRepair starts from the failing test, computes a static backward slice from the failing assertion to remove unrelated test scenarios while preserving state-mutating calls and setup, then executes the program and computes a dynamic backward slice from the last execution event of that assertion, keeping only executed statements that influenced its outcome. These slices are merged into a structured prompt with file paths, Javadoc, and relative line numbers. In the paper's evaluation, this context produces 313 correct fixes on Defects4J (162 in V1.2, 151 in V2.0), 289 fixes on the contamination-reduced Defects4J-Trans benchmark, and 232 fixes under realistic spectrum-based fault localization, and removing the source-side dynamic slice alone lowers correct fixes by 26.5%.

Load-bearing premise

The whole approach stands on the assumption that the executed statements that influenced the failed assertion really contain the bug's cause, and that Slicer4J captures those statements within the five-minute trace budget; if the trace is truncated or imprecise, the LLM receives a context that cannot explain the failure.

Editorial extensions

If this is right

  • If the central claim holds, LLM-based APR should be built around execution-trace slices rather than retrieved static context; the paper reports 313 versus 236 correct Defects4J fixes for the strongest baseline under the same DeepSeek-V3 backbone.
  • Test context quality is as important as source context: reducing the test to only the failing line costs 38.3% of fixes, while using the full test costs 10.0%.
  • The slicing must be paired with iterative validation and patch augmentation: disabling either lowers correct fixes by 18.5% and 16.9%, respectively.
  • The gain transfers across models: with GPT-4o, CausalRepair still fixes 297 Defects4J bugs, so the improvement is attributable to the context rather than one backbone.
  • Under imperfect fault localization with a top-50 candidate list, CausalRepair fixes 232 Defects4J bugs, indicating the causal context compensates for noisy localization.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural boundary of the approach is bugs whose root cause is a missing statement, such as a deleted null check or an uninitialized field: a backward dynamic slice can only contain executed statements, so the absent action never appears in the context.
  • The five-minute slicing budget and the Java-specific dynamic slicer imply that transferring the recipe to other languages depends on the availability of a comparable dynamic slicer; a static fallback would likely narrow the reported advantage.
  • The Defects4J-Trans result (289 fixes) supports robustness against memorization, but the stronger test would be applying CausalRepair to newly collected bugs with no public fix commits, where training-data overlap cannot help.
  • Because cost is driven by token count, the minimal causal context should also reduce latency in interactive repair deployments, not just API expenditure.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes CausalRepair, a test-driven LLM-based automated program repair framework that constructs a 'minimal causal context' by applying static slicing to the failing test and dynamic slicing to the execution trace of the buggy program, and then feeds this context into a conversation-driven repair loop with patch augmentation. The evaluation is conducted on Defects4J V1.2/V2.0, Defects4J-Trans, RWB, and GitBug-Java. With a DeepSeek-V3 backbone, the authors report 313 correct fixes on Defects4J, outperforming the reproduced ReinFix (236) and TSAPR (224) baselines, and an average cost of $0.029 per fixed bug.

Significance. If the reported effect is real, CausalRepair is a substantial advance in LLM-based APR: it directly targets the recognized context-noise problem, provides a concrete mechanism (dual-slicing) for constructing failure-specific contexts, and reports large gains over strong baselines on a standard benchmark. The study also includes ablations, a contamination-reduced benchmark, a realistic-fault-localization robustness check, and releases an artifact, all of which are strengths. However, the central comparative claim currently rests on a prompt that appears to mark the exact buggy line, on hyperparameters selected using the same benchmark that is later reported as the headline result, and on a single stochastic run. These issues must be resolved before the claimed superiority can be accepted.

major comments (4)
  1. [Figure 3 and Section 3.2.3] The prompt template shown in Figure 3 marks the exact defective statement with '// Buggy Line' and instructs the model that 'Buggy lines are marked ... The actual fix may involve changes around these lines or adding new statements if necessary.' This annotation is not described in Algorithm 1's inputs (which are only F_unc and the test suite), is not listed among the position-aware markers in Section 3.2.3, and is not removed in any ablation. If '// Buggy Line' is derived from the known defect location in Defects4J, then CausalRepair receives exact buggy-line information under the 'perfect fault localization' setting, while the reproduced baselines receive unmarked contexts; the headline gap of 313 vs. 236 correct fixes (Table 2) could then be attributable to leaked location information rather than to dual-slicing. Please clarify the source of this marker, add an ablation that removes it, and, if it is ground-truth-derived, rerun the comparison with the same information provided to the baselines.
  2. [Section 5.3, Figure 7] The values m=5 and n=3 are selected by observing performance saturation on Defects4J in Figure 7, and the same Defects4J numbers are then reported as the headline results in Table 2. This is a form of test-set hyperparameter tuning: the reported 313 correct fixes is the best configuration found on the evaluation benchmark, not an unbiased estimate of the method's performance. The authors should tune hyperparameters on a separate validation set (e.g., one Defects4J version while reporting the other, or a held-out subset) and then report the performance of the chosen configuration, or at least report how the headline numbers change across the full grid rather than only the selected point.
  3. [Section 4.5 and Section 5.1] The repair process is stochastic because the sampling temperature is set to 1.0, yet all reported correct-fix counts come from a single run, with no variance or confidence intervals. Because the headline claim is a 77-bug advantage over ReinFix (313 vs. 236), and the reproduced baselines are also stochastic, a single run does not establish that the ordering is reliable. Please report multiple seeds (at least 3-5) with the range of correct fixes, or use deterministic decoding if the exact counts are meant to be reproducible.
  4. [Section 3.2.2 and Section 4.5] The paper's core premise is that the backward dynamic slice of the failing assertion contains the causally responsible statements, but this premise is never directly validated. No statistics are reported on slice size, precision, or completeness, and Section 4.5 notes that a 5-minute timeout causes the dynamic context to be omitted without saying how often this occurs. The ablation in Table 4 shows that removing dynamic slicing hurts performance, but it does not measure whether the slices actually contain the root cause when repairs succeed or fail. The authors should report the success rate of dynamic slicing, average slice size, and the fraction of correct repairs whose slice contains the ground-truth fix location, so that the 'causal context' claim can be assessed.
minor comments (5)
  1. [Algorithm 1, line 1] The function IdentifyFail(T, F_unc) is described only as 'locate the failing test function'; the paper should specify the procedure used when multiple tests fail or when the failing test is not uniquely determined.
  2. [Section 3.2.3 and Figure 3] The text lists only File Path Headers, Intent Preservation, and Position-Aware Markers as semantic anchors, but Figure 3 also shows external method/field lists and the 'Buggy Line' annotation. Please either align the figure with the described prompt construction or describe all prompt elements in the text.
  3. [Section 6.2] The realistic fault-localization experiment reports 232 correct fixes with GZoltar/Ochiai top-50 candidates, but no baseline is evaluated under the same setting, so the result is not a comparative robustness check. Adding a ReinFix or TSAPR run under the same GZoltar setting would make this experiment interpretable.
  4. [Section 5.5, Table 6] The cost column is labeled 'Money/Bug' but it is not stated whether the denominator is the number of fixed bugs or the number of all attempted bugs; please state the exact formula so the cost comparison is reproducible.
  5. [Throughout] The term 'minimal causal context' is used as a technical claim, but no operational definition of minimality is given. I suggest defining it in terms of a measurable quantity, such as the size of the resulting context relative to the full function and test, or using a weaker term like 'reduced causal context'.

Circularity Check

2 steps flagged · score 7.0 of 10

Prompt template leaks the exact buggy line into the LLM, and Phase-2 budgets are tuned on the same Defects4J benchmark that is then reported as the headline result.

  1. other [Figure 3; Sections 3.2.3 and 4.5; Algorithm 1]
    "copy.data = new java.util.ArrayList(); // Buggy Line ... Buggy lines are marked with '// Buggy Line' as hints. The actual fix may involve changes around these lines or adding new statements if necessary."

    Algorithm 1 takes only F_unc and the test suite T, and Section 3.2.3 describes only relative '// Line N:' position markers. The '// Buggy Line' hint shown in Figure 3 is not produced by the static or dynamic slicing pipeline and matches the ground-truth fault location of the benchmark bug. Under the perfect-fault-localization setting, the model already receives the buggy function; adding statement-level ground truth supplies exactly the location that dual-slicing is claimed to discover. Reproduced baselines without this marker face a strictly harder task, so the headline 313-versus-236 gap is at least partly forced by an oracle hint rather than derived from the dual-slicing method.

  2. fitted input called prediction [Section 5.3, Figure 7]
    "As shown in Figure 7, we observe that the repair performance generally improves as m and n increase... However, the performance gain diminishes and saturates after m=5 and n=3. Considering the trade-off between repair effectiveness and computational cost..., we identify m=5 and n=3 as the optimal configuration for our main experiments."

    The repair budget (m, n) is selected by measuring correct fixes on Defects4J, the same benchmark on which the headline 313-bug result is reported. The headline is therefore the maximum of a configuration sweep over the evaluation set, not an independent estimate for a fixed method. This selection-on-the-test-set step partially manufactures the reported effectiveness gain and means the headline number is a fitted result, not a clean prediction of the method's default configuration.

full rationale

The internal derivation chain of CausalRepair (test-side static slicing, source-side dynamic slicing, AST reconstruction, then LLM repair) is not self-definitional in the usual sense: dynamic slicing is a standard backward dependence computation, and there is no load-bearing import of a uniqueness theorem from the authors' prior work. However, two problems compromise the central comparative claim. First, the prompt template in Figure 3 injects '// Buggy Line' markers that are absent from Algorithm 1's stated inputs and from the reconstruction description in Section 3.2.3; the marked line coincides with the benchmark's known fault, giving the LLM exact buggy-line information that the reproduced baselines do not receive. Second, the Phase-2 budget m and n is tuned on the same Defects4J benchmark that is then used for the headline 313-bug result, so the reported effectiveness is partly a selected maximum over the evaluation set. Both issues make the 77-bug advantage over ReinFix not cleanly attributable to dual-slicing. No self-citation chain is load-bearing; the circularity signal is the hidden oracle hint and the benchmark-tuned hyperparameters.

Assumptions & free parameters 4 free parameters · 5 assumptions · 0 invented entities

The central claim rests on empirical benchmark evaluation, not a closed-form derivation. The main unpaid-for inputs are hyperparameters tuned on the test benchmark, the assumption that dynamic slices capture true causality, the perfect fault localization assumption, and the contamination-reduction assumption for Defects4J-Trans.

free parameters (4)
  • Maximum repair attempts (m) = 5
    Chosen from Fig. 7 where gains saturate near m=5 on Defects4J; the benchmark used for tuning is the same one used for the headline result.
  • Maximum iterative interactions (n) = 3
    Chosen from Fig. 7; performance saturates near n=3, again tuned on Defects4J.
  • Patch augmentation queries = 10
    Set so the total patch budget is 25 (5x3+10); no sensitivity analysis is reported for this value.
  • Dynamic slicing timeout = 5 minutes
    If the dynamic slicer times out or crashes, dynamic context is omitted; the effect of this timeout on results is not analyzed.
assumptions (5)
  • domain assumption Backward dynamic slicing of the failing assertion's execution event yields the minimal set of statements causally responsible for the failure.
    This is the core premise of Phase 1, Section 3.2.2; if the slice misses root-cause statements, the LLM lacks needed evidence.
  • domain assumption The perfect fault localization setting (the buggy function is known a priori) is representative enough to compare repair methods.
    Main experiments in Section 4.5 use perfect FL; the realistic-FL experiment (Section 6.2) only partially mitigates this.
  • domain assumption Defects4J-Trans transformations eliminate training-data contamination because the dataset was released after DeepSeek-V3's cutoff.
    Section 5.4 treats release date as proxy for contamination; semantic-preserving transformations may still leave memorizable patterns.
  • domain assumption Slicer4J's dynamic dependence graph is precise enough for the target bugs.
    The entire source context depends on Slicer4J's accuracy; the paper does not evaluate slicer precision.
  • domain assumption Marking the buggy line as a '// Buggy Line' hint does not give an unfair advantage over baselines.
    Figure 3 shows the prompt includes statement-level buggy-line hints; the paper does not state whether reproduced baselines receive the same hint.

how reviews work

0 comments
Cite this review

Pith. "Pith review of CausalRepair: Bridging the Causality Gap in Large Language Model-Based Automated Program Repair via Dual-Slicing." pith.science (2026). https://pith.science/paper/LB7ZVAQ3

@misc{pith2026260810613,
  author       = {Pith},
  title        = {Pith review of: CausalRepair: Bridging the Causality Gap in Large Language Model-Based Automated Program Repair via Dual-Slicing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LB7ZVAQ3}},
  note         = {Machine review of arXiv:2608.10613}
}
abstract

Automated Program Repair (APR) has recently benefited from Large Language Models (LLMs), yet their effectiveness heavily depends on repair context. Existing LLM-based APR methods suffer from a causality gap: test contexts can be noisy or incomplete, while source contexts derived from static analysis often contain irrelevant and unexecuted code, misleading LLMs from identifying the true root cause. To address this issue, we propose CausalRepair, a conversation-driven APR framework based on minimal causal context, i.e., the essential dependencies required to explain a failure. CausalRepair employs a dual-slicing strategy: context-aware static slicing purifies test semantics, while execution-trace-based dynamic slicing captures precise runtime dependencies in source code. Together, they construct compact, causally relevant contexts to guide iterative repair. We evaluate CausalRepair on Defects4J V1.2, V2.0, and Defects4J-Trans using DeepSeek-V3. CausalRepair correctly fixes 313 bugs on Defects4J, outperforming state-of-the-art approaches such as ReinFix and TSAPR, while reducing the average repair cost to $0.029 per bug.

Figures

Figures reproduced from arXiv: 2608.10613 by the authors.

Figure 1
Figure 1. Motivation Example of CausalRepair. equivalent and correct. Therefore, to repair this bug, the model must understand state dependency, meaning the valid search space should be determined by the dynamically changing size. Context A: Ambiguous Test Context. When the repair prompt includes only the failing assertion and error message, as shown in [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Overview of CausalRepair. 3 Approach 3.1 Framework Overview In this section, we present the overall workflow of CausalRepair (as illustrated in [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Illustration of the Prompt Construction. [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Bug Fix Venn Diagram on Defects4J (CausalRepair, ContrastRepair, ThinkRepair, TSAPR, ReinFix) [PITH_FULL_IMAGE:figures/full_fig_p012_4.png]
Figure 5
Figure 5. Figure 5: Unique Fix Generated by CausalRepair for Lang-18. [PITH_FULL_IMAGE:figures/full_fig_p013_5.png]
Figure 6
Figure 6. Figure 6: Dual-Slicing Context for the Lang-18 Case Study. [PITH_FULL_IMAGE:figures/full_fig_p013_6.png]
Figure 7
Figure 7. Figure 7: Impact of hyperparameter settings (𝑚 and 𝑛) on repair effectiveness. As shown in [PITH_FULL_IMAGE:figures/full_fig_p016_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

80 extracted references · 20 canonical work pages

  1. [1]

    [n. d.]. Model - OpenAI API. [Online; accessed 2025-11-30]. https://platform.openai.com/docs/models/gpt-4o? snapshot=gpt-4o-2024-05-13

    work page 2025

  2. [2]

    [n. d.]. SiliconFlow – AI Infrastructure for LLMs & Multimodal Models. [Online; accessed 2026-01-16]. https: //www.siliconflow.com/

    work page 2026

  3. [3]

    Rui Abreu, Peter Zoeteweij, and Arjan JC Van Gemund. 2007. On the accuracy of spectrum-based fault localization. In Testing: Academic and industrial conference practice and research techniques-MUTATION (TAICPART-MUTATION 2007). IEEE, 89–98. doi:10.1109/taic.part.2007.13

    doi:10.1109/taic.part.2007.13 2007

  4. [4]

    Mithun Acharya and Brian Robinson. 2011. Practical change impact analysis based on static program slicing for industrial software systems. InProceedings of the 33rd international conference on software engineering. 746–755. doi:10.1145/1985793.1985898

    arXiv 2011

  5. [5]

    Hiralal Agrawal and Joseph R Horgan. 1990. Dynamic program slicing.ACM SIGPlan Notices25, 6 (1990), 246–256. doi:10.1145/93548.93576

    work page arXiv 1990

  6. [6]

    Khaled Ahmed, Mieszko Lis, and Julia Rubin. 2021. Slicer4J: a dynamic slicer for Java. InProceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 1570–1574. doi:10.1145/3468264.3473123

    arXiv 2021

  7. [7]

    David Binkley. 1998. The application of program slicing to regression testing.Information and software technology40, 11-12 (1998), 583–594. doi:10.1016/s0950-5849(98)00085-8

    work page doi:10.1016/s0950-5849(98)00085-8 1998

  8. [8]

    David Binkley and Mark Harman. 2004. A survey of empirical results on program slicing.Advances in Computers62, 105178 (2004), 105–178. doi:10.1016/s0065-2458(03)62003-6

    work page doi:10.1016/s0065-2458(03)62003-6 2004

Show all 80 references
  1. [10]

    José Campos, André Riboira, Alexandre Perez, and Rui Abreu. 2012. Gzoltar: an eclipse plug-in for testing and debugging. InProceedings of the 27th IEEE/ACM international conference on automated software engineering. 378–381. doi:10.1145/2351676.2351752

    2012

  2. [11]

    Zimin Chen, Steve Kommrusch, Michele Tufano, Louis-Noël Pouchet, Denys Poshyvanyk, and Martin Monperrus. 2019. Sequencer: Sequence-to-sequence learning for end-to-end program repair.IEEE Transactions on Software Engineering 47, 9 (2019), 1943–1959. doi:10.1109/tse.2019.2940179

    2019

  3. [12]

    Favio DeMarco, Jifeng Xuan, Daniel Le Berre, and Martin Monperrus. 2014. Automatic repair of buggy if conditions and missing preconditions with smt. InProceedings of the 6th international workshop on constraints in software testing, verification, and analysis. 30–39. doi:10.11...

    2014

  4. [13]

    Richard A DeMillo, Hsin Pan, and Eugene H Spafford. 1996. Critical slicing for software fault localization.ACM SIGSOFT Software Engineering Notes21, 3 (1996), 121–134. doi:10.1145/229000.226310

    1996

  5. [14]

    Dawn Drain, Colin B Clement, Guillermo Serrato, and Neel Sundaresan. 2021. Deepdebug: Fixing python bugs using stack traces, backtranslation, and code skeletons.arXiv preprint arXiv:2105.09352(2021). doi:10.48550/arxiv.2105.09352

    2021 doi arXiv

  6. [15]

    Jeanne Ferrante, Karl J Ottenstein, and Joe D Warren. 1987. The program dependence graph and its use in optimization. ACM Transactions on Programming Languages and Systems (TOPLAS)9, 3 (1987), 319–349. doi:10.1145/24039.24041

    1987

  7. [16]

    Keith Gallagher and David Binkley. 2008. Program slicing. In2008 Frontiers of Software Maintenance. IEEE, 58–67. doi:10.1109/fosm.2008.4659249

    2008

  8. [17]

    Duck, Ruyi Ji, Yingfei Xiong, and Abhik Roychoudhury

    Xiang Gao, Bo Wang, Gregory J. Duck, Ruyi Ji, Yingfei Xiong, and Abhik Roychoudhury. 2021. Beyond Tests: Program Vulnerability Repair via Crash Constraint Extraction.ACM Trans. Softw. Eng. Methodol.30, 2, Article 14 (Feb. 2021), 27 pages. doi:10.1145/3418461

    2021 doi

  9. [18]

    Luca Gazzola, Daniela Micucci, and Leonardo Mariani. 2018. Automatic software repair: A survey. InProceedings of the 40th International Conference on Software Engineering. 1219–1219. doi:10.1109/tse.2017.2755013

    2018

  10. [20]

    Rajiv Gupta, Mary Jean Harrold, and Mary Lou Soffa. 1996. Program slicing-based regression testing techniques. Software Testing, Verification and Reliability6, 2 (1996), 83–111. doi:10.1002/(sici)1099-1689(199606)6:2<83::aid-stvr112> 3.0.co;2-9

    1996 doi

  11. [21]

    Susan Horwitz, Thomas Reps, and David Binkley. 1990. Interprocedural slicing using dependence graphs.ACM Transactions on Programming Languages and Systems (TOPLAS)12, 1 (1990), 26–60. doi:10.1145/77606.77608

    1990

  12. [22]

    Haichuan Hu, Ye Shang, Weifeng Sun, and Quanjun Zhang. 2025. TSAPR: A Tree Search Framework For Automated Program Repair.arXiv preprint arXiv:2507.01827(2025). doi:10.48550/arxiv.2507.01827

    2025 doi arXiv

  13. [23]

    Jinru Hua, Mengshi Zhang, Kaiyuan Wang, and Sarfraz Khurshid. 2018. Sketchfix: a tool for automated program repair approach using lazy candidate generation. InProceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Founda...

    2018 doi

  14. [24]

    Jiajun Jiang, Yingfei Xiong, Hongyu Zhang, Qing Gao, and Xiangqun Chen. 2018. Shaping program repair space with existing patches and similar code. InProceedings of the 27th ACM SIGSOFT international symposium on software testing and analysis. 298–309. doi:10.1145/3213846.3213871

    2018

  15. [26]

    Nan Jiang, Thibaud Lutellier, and Lin Tan. 2021. Cure: Code-aware neural machine translation for automatic program repair. In2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 1161–1173. doi:10.1109/ icse43902.2021.00107

    2021

  16. [27]

    René Just, Darioush Jalali, and Michael D Ernst. 2014. Defects4J: A database of existing faults to enable controlled testing studies for Java programs. InProceedings of the 2014 international symposium on software testing and analysis. 437–440. doi:10.1145/2610384.2628055

    2014

  17. [28]

    Jiaolong Kong, Xiaofei Xie, Mingfei Cheng, Shangqing Liu, Xiaoning Du, and Qi Guo. 2025. Contrastrepair: Enhancing conversation-based automated program repair via contrastive test case pairs.ACM Transactions on Software Engineering and Methodology34, 8 (2025), 1–31. doi:10.114...

    2025 doi

  18. [29]

    Bogdan Korel and Janusz Laski. 1988. Dynamic program slicing.Information processing letters29, 3 (1988), 155–163. doi:10.1016/0020-0190(88)90054-3

    1988 doi

  19. [30]

    Xuan-Bach D Le, Duc-Hiep Chu, David Lo, Claire Le Goues, and Willem Visser. 2017. S3: syntax-and semantic-guided repair synthesis via programming by examples. InProceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering. 593–604. doi:10.1145/3106237.3106309

    2017

  20. [31]

    Xuan Bach D Le, David Lo, and Claire Le Goues. 2016. History driven program repair. In2016 IEEE 23rd international conference on software analysis, evolution, and reengineering (SANER), Vol. 1. IEEE, 213–224. doi:10.1109/saner.2016.76

    2016 doi

  21. [32]

    Claire Le Goues, ThanhVu Nguyen, Stephanie Forrest, and Westley Weimer. 2011. Genprog: A generic method for automatic software repair.Ieee transactions on software engineering38, 1 (2011), 54–72. doi:10.1109/tse.2011.104

    2011 doi

  22. [33]

    Claire Le Goues, Michael Pradel, and Abhik Roychoudhury. 2019. Automated program repair.Commun. ACM62, 12 (2019), 56–65. doi:10.1145/3318162

    2019 doi

  23. [34]

    Ahmed Lekssays, Hamza Mouhcine, Khang Tran, Ting Yu, and Issa Khalil. 2025. {LLMxCPG}:{Context-Aware} vulnerability detection through code property {Graph-Guided} large language models. In34th USENIX Security Symposium (USENIX Security 25). USENIX Association, Seattle, WA, 489...

    2025

  24. [35]

    Fengjie Li, Jiajun Jiang, Jiajun Sun, and Hongyu Zhang. 2025. Evaluating the Generalizability of LLMs in Automated Program Repair. In2025 IEEE/ACM 47th International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER). IEEE, 91–95. doi:10.1109/icse-n...

    2025

  25. [36]

    Yi Li, Shaohua Wang, and Tien N Nguyen. 2020. Dlfix: Context-based code transformation learning for automated program repair. InProceedings of the ACM/IEEE 42nd international conference on software engineering. 602–614. doi:10. 1145/3377811.3380345

    2020

  26. [39]

    Linhao. 2026. CausalRepair. Software artifact. doi:10.5281/zenodo.20953899

    2026 doi

  27. [40]

    Kui Liu, Anil Koyuncu, Dongsun Kim, and Tegawendé F Bissyandé. 2019. Avatar: Fixing semantic bugs with fix patterns of static analysis violations. In2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 1–12. doi:10.1109/saner...

    2019

  28. [41]

    Kui Liu, Anil Koyuncu, Dongsun Kim, and Tegawendé F Bissyandé. 2019. TBar: Revisiting template-based automated program repair. InProceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis. 31–42. doi:10.1145/3293882.3330577

    2019

  29. [42]

    Kui Liu, Anil Koyuncu, Kisub Kim, Dongsun Kim, and Tegawendé F Bissyandé. 2018. LSRepair: Live search of fix ingredients for automated program repair. In2018 25th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 658–662. doi:10.1109/apsec.2018.00085

    2018

  30. [43]

    Nelson F Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. 2024. Lost in the middle: How language models use long contexts.Transactions of the Association for Computational Linguistics12 (2024), 157–173. doi:10.1162/tacl_a_00638

    2024 doi

  31. [44]

    Fan Long and Martin Rinard. 2015. Staged program repair with condition synthesis. InProceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering. 166–178. doi:10.1145/2786805.2786811 Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA134. Publication d...

    2015

  32. [45]

    Thibaud Lutellier, Hung Viet Pham, Lawrence Pang, Yitong Li, Moshi Wei, and Lin Tan. 2020. Coconut: combining context-aware neural translation models using ensemble for program repair. InProceedings of the 29th ACM SIGSOFT international symposium on software testing and analys...

    2020

  33. [46]

    Matias Martinez and Martin Monperrus. 2016. Astor: A program repair library for java. InProceedings of the 25th international symposium on software testing and analysis. 441–444. doi:10.1145/2931037.2948705

    2016

  34. [47]

    Sergey Mechtaev, Jooyong Yi, and Abhik Roychoudhury. 2016. Angelix: Scalable multiline program patch synthesis via symbolic analysis. InProceedings of the 38th international conference on software engineering. 691–701. doi:10.1145/ 2884781.2884807

    2016

  35. [48]

    Xiangxin Meng, Xu Wang, Hongyu Zhang, Hailong Sun, and Xudong Liu. 2022. Improving fault localization and program repair with deep semantic features and transferred knowledge. InProceedings of the 44th International Conference on Software Engineering. 1169–1180. doi:10.1145/35...

    2022

  36. [50]

    Daye Nam, Andrew Macvean, Vincent Hellendoorn, Bogdan Vasilescu, and Brad Myers. 2024. Using an llm to help with code understanding. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering. 1–13. doi:10.1145/3597503.3639187

    2024

  37. [51]

    James Newsome and Dawn Xiaodong Song. 2005. Dynamic Taint Analysis for Automatic Detection, Analysis, and SignatureGeneration of Exploits on Commodity Software. InNetwork and Distributed System Security Symposium. https://api.semanticscholar.org/CorpusID:99191

    2005

  38. [52]

    2025.{APPATCH}: Automated adaptive prompting large language models for{Real-World} software vulnerability patching

    Yu Nong, Haoran Yang, Long Cheng, Hongxin Hu, and Haipeng Cai. 2025.{APPATCH}: Automated adaptive prompting large language models for{Real-World} software vulnerability patching. In34th USENIX Security Symposium (USENIX Security 25). USENIX Association, Seattle, WA, 4481–4500....

    2025

  39. [53]

    Yue Pan, Zimin Chen, Siyu Lu, Zhaoyang Chu, Xiang Li, Han Li, Yang Feng, Claire Le Goues, Federica Sarro, Martin Monperrus, and He Ye. 2025. Prometheus: Towards Long-Horizon Codebase Navigation for Repository-Level Problem Solving. doi:10.48550/arXiv.2507.19942

    2025 doi

  40. [54]

    Barr, and Sergey Mechtaev

    Nikhil Parasaram, Huijie Yan, Boyu Yang, Zineb Flahy, Abriele Qudsi, Damian Ziaber, Earl T. Barr, and Sergey Mechtaev

  41. [55]

    Solmaz Salimi and Mehdi Kharrazi. 2022. VulSlicer: Vulnerability detection through code slicing.Journal of Systems and Software193 (2022), 111450. doi:10.1016/j.jss.2022.111450

    2022

  42. [56]

    Jiahao Shi and Tianyi Zhang. 2025. RESCUE: Retrieval Augmented Secure Code Generation.arXiv preprint arXiv:2510.18204(2025). doi:10.48550/arxiv.2510.18204

    2025 doi

  43. [57]

    André Silva, Sen Fang, and Martin Monperrus. 2025. Repairllama: Efficient representations and fine-tuned adapters for program repair.IEEE Transactions on Software Engineering(2025). doi:10.1109/tse.2025.3581062

    2025

  44. [58]

    André Silva, Nuno Saavedra, and Martin Monperrus. 2024. Gitbug-java: A reproducible benchmark of recent java bugs. InProceedings of the 21st International Conference on Mining Software Repositories. 118–122. doi:10.1145/3643991.3644884

    2024

  45. [59]

    Xiaolong Tian. 2024. Evaluating the repair ability of LLM under different prompt settings. In2024 IEEE International Conference on Software Services Engineering (SSE). IEEE, 313–322. doi:10.1109/sse62657.2024.00053

    2024

  46. [60]

    Frank Tip. 1994. A survey of program slicing techniques.J. Program. Lang.3 (1994). https://api.semanticscholar.org/ CorpusID:9882901

    1994

  47. [61]

    Mark Weiser. 1984. Program Slicing.IEEE Transactions on Software EngineeringSE-10, 4 (1984), 352–357. doi:10.1109/ TSE.1984.5010248

    1984

  48. [62]

    Ming Wen, Junjie Chen, Rongxin Wu, Dan Hao, and Shing-Chi Cheung. 2018. Context-aware patch generation for better automated program repair. InProceedings of the 40th international conference on software engineering. 1–11. doi:10.1145/3180155.3180233

    2018

  49. [63]

    Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2025. Demystifying LLM-Based Software Engineering Agents.Proc. ACM Softw. Eng.2, FSE, Article FSE037 (June 2025), 24 pages. doi:10.1145/3715754

    2025 doi

  50. [64]

    Chunqiu Steven Xia, Yifeng Ding, and Lingming Zhang. 2023. The plastic surgery hypothesis in the era of large language models. In2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 522–534. doi:10.1109/ase56229.2023.00047

    2023

  51. [65]

    Chunqiu Steven Xia, Yuxiang Wei, and Lingming Zhang. 2023. Automated program repair in the era of large pre-trained language models. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 1482–1494. doi:10.1109/icse48619.2023.00129

    2023

  52. [66]

    Chunqiu Steven Xia and Lingming Zhang. 2022. Less training, more repairing please: revisiting automated program repair via zero-shot learning. InProceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering....

    2022

  53. [68]

    Baowen Xu, Ju Qian, Xiaofang Zhang, Zhongqiang Wu, and Lin Chen. 2005. A brief survey of program slicing.ACM SIGSOFT Software Engineering Notes30, 2 (2005), 1–36. doi:10.1145/1050849.1050865

    2005

  54. [69]

    Jifeng Xuan, Matias Martinez, Favio Demarco, Maxime Clement, Sebastian Lamelas Marcote, Thomas Durieux, Daniel Le Berre, and Martin Monperrus. 2016. Nopol: Automatic repair of conditional statement bugs in java programs.IEEE Transactions on Software Engineering43, 1 (2016), 34...

    2016

  55. [70]

    Pengyu Xue, Linhao Wu, Zhen Yang, Chengyi Wang, Xiang Li, Yuxiang Zhang, Jia Li, Ruikai Jin, Yifei Pei, Zhaoyan Shen, et al. 2025. ClassEval-T: Evaluating Large Language Models in Class-Level Code Translation.Proceedings of the ACM on Software Engineering2, ISSTA (2025), 1421–...

    2025 doi

  56. [71]

    Pengyu Xue, Linhao Wu, Zhen Yang, Zhongxing Yu, Zhi Jin, Ge Li, Yan Xiao, Shuo Liu, Xinyi Li, Hongyi Lin, et al

  57. [72]

    Pengyu Xue, Linhao Wu, Zhongxing Yu, Zhi Jin, Zhen Yang, Xinyi Li, Zhenyu Yang, and Yue Tan. 2024. Automated commit message generation with large language models: An empirical study and beyond.IEEE Transactions on Software Engineering(2024). doi:10.1109/tse.2024.3478317

    2024

  58. [73]

    Pengyu Xue, Kunwu Zheng, Zhen Yang, Yifei Pei, Linhao Wu, Jiahui Dong, Xiapu Luo, Yan Xiao, Fei Liu, Yuxuan Zhang, Xiran Lyu, Xianhang Li, Xuanyu Zhu, and Chengyi Wang. 2026. TransLibEval: Demystify Large Language Models’ Capability in Third-Party Library-Targeted Code Transla...

    2026 doi

  59. [74]

    Boyang Yang, Zijian Cai, Fengling Liu, Bach Le, Lingming Zhang, Tegawendé F Bissyandé, Yang Liu, and Haoye Tian

  60. [75]

    Boyang Yang, Luyao Ren, Xin Yin, Jiadong Ren, Haoye Tian, and Shunfu Jin. 2025. Input Reduction Enhanced LLM-based Program Repair.arXiv preprint arXiv:2507.15251(2025). doi:10.48550/arxiv.2507.15251

    2025 doi

  61. [76]

    Chen Yang, Lin Yang, Ziqi Wang, Dong Wang, Jianyi Zhou, and Junjie Chen. 2025. Clarifying Semantics of In-Context Examples for Unit Test Generation. (2025), 3046–3057. doi:10.1109/ASE63991.2025.00250

    2025

  62. [77]

    doi:10.48550/arxiv.2506.23749

    A Survey of LLM-based Automated Program Repair: Taxonomies, Design Paradigms, and Applications.arXiv preprint arXiv:2506.23749(2025). doi:10.48550/arxiv.2506.23749

    2025 doi

  63. [78]

    He Ye, Matias Martinez, and Martin Monperrus. 2022. Neural program repair with execution-based backpropagation. InProceedings of the 44th international conference on software engineering. 1506–1518. doi:10.1145/3510003.3510222

    2022

  64. [79]

    He Ye and Martin Monperrus. 2024. Iter: Iterative neural repair for multi-location patches. InProceedings of the 46th IEEE/ACM international conference on software engineering. 1–13. doi:10.1145/3597503.3623337

    2024

  65. [80]

    He Ye, Matias Martinez, Xiapu Luo, Tao Zhang, and Martin Monperrus. 2022. Selfapr: Self-supervised program repair with test execution diagnostics. InProceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering. 1–13. doi:10.1145/3551349.3556926

    2022

  66. [82]

    Jiayi Zhang, Kai Huang, Jian Zhang, Yang Liu, and Chunyang Chen. 2025. Repair Ingredients Are All You Need: Improving Large Language Model-Based Program Repair via Repair Ingredients Search.arXiv preprint arXiv:2506.23100 (2025). doi:10.48550/arxiv.2506.23100

    2025 doi arXiv

  67. [83]

    He Ye, Aidan ZH Yang, Chang Hu, Yanlin Wang, Tao Zhang, and Claire Le Goues. 2025. Adverintent-agent: Adversarial reasoning for repair based on inferred program intent.Proceedings of the ACM on Software Engineering2, ISSTA (2025), 1398–1420. doi:10.1145/3728939

    2025 doi

  68. [84]

    Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. 2024. Autocoderover: Autonomous program improvement. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1592–1604. doi:10.1145/3650212.3680384

    2024

  69. [85]

    Qihao Zhu, Zeyu Sun, Yuan-an Xiao, Wenjie Zhang, Kang Yuan, Yingfei Xiong, and Lu Zhang. 2021. A syntax-guided edit decoder for neural program repair. InProceedings of the 29th ACM joint meeting on European software engineering conference and symposium on the foundations of so...

    2021

  70. [86]

    Quanjun Zhang, Chunrong Fang, Yuxiang Ma, Weisong Sun, and Zhenyu Chen. 2023. A survey of learning-based automated program repair.ACM Transactions on Software Engineering and Methodology33, 2 (2023), 1–69. doi:10.1145/ 3631974

    2023

  71. [2024]

    arXiv preprint arXiv:2410.07516(2024)

    Exploring and Lifting the Robustness of LLM-powered Automated Program Repair with Metamorphic Testing. arXiv preprint arXiv:2410.07516(2024). doi:10.48550/arxiv.2410.07516

    2024 doi arXiv

  72. [2025]

    (2025), 2574–2586

    The Fact Selection Problem in LLM-Based Program Repair. (2025), 2574–2586. doi:10.1109/ICSE55347.2025.00162

    2025

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.