Pith. sign in

REVIEW 4 major objections 5 minor 61 references

RecovSlicing claims that dynamic data dependency can be computed from a single partially instrumented run: an LLM recovers unrecorded variable values and structures, and backward definition search finds the defining step.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

RecovSlicing recovers dynamic data dependencies from partially recorded execution traces by using a language model to reconstruct missed variable values and aliases.

T0 review reviewed 2026-08-05 challenge →

load-bearing objection A genuinely new idea—LLM recovers missing dependencies from a partial trace—that deserves a serious referee, but the main evaluation is too close to the generating model to prove the generalizability claim. the 4 major comments →

arxiv 2508.18721 v5 pith:DAUC2RLI submitted 2025-08-26 cs.SE

LLM as an Execution Estimator: Recovering Missing Dependency for Practical Time-travelling Debugging

classification cs.SE
keywords dynamic data dependencyprogram slicingLLM-based execution estimationpartial tracetime-travelling debuggingalias inferencein-context learningregression bug localization
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The reading

Determining which step defined a variable read at a program step usually forces a choice: instrument everything, including library internals that are costly or impossible to trace, or re-run the program until the dependency appears, which fails for non-deterministic programs. RecovSlicing claims a third path: instrument only the application code, and use an LLM to reconstruct the unrecorded part of the execution from the partial trace, so the dynamic data dependency can be computed from a single ordinary run. The paper argues that with an automatically synthesized, fully instrumented miniature analog of the query step as in-context context, the LLM can recover the query variable's value and structure, and that a combination of alias inference and backward definition search yields correct dependencies. On 8300 dependencies over three benchmarks the reported precision/recall reach 80.3%, 91.1%, and 98.3%, far above the best baseline, and integrating the tool into a dual-slicing regression localizer raises the success rate from 0.73 to 0.89 on Defects4J. If right, it makes time-travelling debugging and dependency analysis practical where full instrumentation or re-execution is not.

Core claim

RecovSlicing's central claim is that dynamic data dependency — the answer to 'why does this variable have this value?' — does not require a complete trace. From a partially instrumented trace and a query step/variable, the approach asks an LLM to estimate the missed execution: first recovering the query variable's runtime value and its structural access path (e.g., sharedList.elementData[0].value[1]) as an object graph rooted at a recorded variable, then walking the trace backward and, with LLM-assisted alias/definition checks at each call site, identifying the step that most recently defined the recovered variable or one of its aliases. The paper treats the LLM as an execution estimator rat

What carries the argument

Variable recovery via adaptive in-context learning: from the query step's code and the recorded value of a root variable, a small executable program ending in the same query step is synthesized, fully instrumented, and executed so its recorded object graph becomes a concrete in-context example for the LLM; the LLM then predicts the target object graph. Definition inference then operates on this graph: an alias-inference pass links graph nodes to recorded variables that share a memory location (must-alias analysis plus conservative LLM prompt for call sites), and a backward scan over the trace asks, at each candidate call-site step, whether the step defines the query variable, returning the m

Load-bearing premise

RecovSlicing assumes that a fully instrumented, synthesized example program produces an object graph similar enough to the target query's object state that the LLM's in-context recovery transfers; if the synthesized analog differs in control flow, library behavior, or alias pattern, the recovered value or structure will be wrong and the backward definition search fails.

What would settle it

Run RecovSlicing on the WeakHashMap example from Section 5.1.5 (query map.table[14].hash defined by map.put) with only application-level instrumentation and compare its recovered definition step to a fully instrumented ground-truth trace; if the recovered value and defining step are wrong, the LLM-based recovery part of the claim is falsified. More generally, instrument a partially recorded library-heavy program fully and measure whether RecovSlicing's recovered object graph matches ground truth on variables with nontrivial aliasing or hashing order.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • A developer can ask 'why this value' for any read, including reads inside library returns, without instrumenting the library or re-running the program.
  • Non-deterministic and flaky programs become analyzable, since a single recorded run suffices for dependency recovery.
  • The technique transfers to unseen libraries because the in-context example is synthesized from the query itself, not from a hand-written library summary.
  • End-to-end, recovering these missing dependencies raises a dual-slicing regression localizer's success rate from 0.73 to 0.89 on Defects4J.
  • Accuracy holds across both remote and local 27B models, so offline deployment remains viable.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The recovered object graph could double as a confidence signal: when the LLM's answer changes across randomized resamples or across different synthesized analogs, the dependency should be flagged as uncertain; the paper does not exploit this.
  • The same recovery could feed demand-driven full slicing: computing one-step dependencies per query and composing them recursively along the trace would yield a full slice while materializing only the needed portions.
  • An obvious stress test is container/hashing-order-dependent libraries (WeakHashMap, identity-based maps), where the paper's reported failure case suggests recovery quality is controlled by how faithfully the synthesized example reproduces the target's internal order.
  • Applied to other languages, the approach only needs a toString-like rendering plus a way to synthesize small programs; nothing in the core mechanism is Java-specific, though the evaluation is Java-only.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper proposes RecovSlicing, a dynamic data dependency analyzer for Java that uses an LLM to recover missing execution information from a partially instrumented trace. Given a query step and a query variable (including implicit library variables), RecovSlicing estimates the unrecorded object graph via adaptive in-context learning, infers aliases, and searches backward for the defining step. The approach is evaluated on 8300 data dependencies across three benchmarks (Hierarchical Synthetic, ND-Slicer translated to Java, LLM-Slicer) and integrated into the Tregression time-travel debugging agent on 489 Defects4J bugs. Reported precision/recall ranges are 80.3%–98.3%, with best baselines at 39.0%–82.0% precision; the debugging success rate improves from 0.73 to 0.89.

Significance. If the reported results hold, RecovSlicing addresses a real limitation of dynamic slicing: obtaining dynamic data dependencies without exhaustive instrumentation or re-execution. The idea of using an LLM as an execution estimator grounded in a partial trace is timely and potentially impactful for time-travel debugging. The paper includes several strengths: it compares against multiple baselines, provides a component-wise analysis, an ablation of the in-context learning component, and an end-to-end application study. However, the evidence as presented is not yet convincing for the paper's central generalization claim, primarily because the main benchmarks are LLM-generated or LLM-translated and no statistical significance is established. The core mechanism is interesting, but the evaluation needs to be strengthened before the claimed advantages can be accepted.

major comments (4)
  1. [§5.1.2, Table 2] The main benchmark (Hierarchical Synthetic Dataset) is 'systematically enhanced using LLMs' and the approach uses GPT-4o, and the ND-Slicer dataset is translated from Python to Java via an LLM. This creates a circularity: the LLM may be solving tasks from the same distribution it was prompted on, and the reported 80.34% on the synthetic set may not transfer to arbitrary real-world libraries, which is the motivating scenario in §1. I recommend adding a benchmark with real-world, third-party or custom library code whose object graph is unlikely to be in the LLM's training data, with per-dependency ground truth from exhaustive instrumentation.
  2. [§5.4, Table 6] The Defects4J experiment reports only aggregate debugging success rate on 489 of 835 bugs selected by Tregression's trace-length limit, and does not measure per-dependency slicing accuracy against exhaustive instrumentation. The selection bias and the lack of dependency-level ground truth make it difficult to attribute the 0.73→0.89 improvement specifically to the slicing mechanism. I recommend reporting per-dependency precision/recall on a random sample of the selected bugs with exhaustive instrumentation, and clarifying how the subset affects the comparison.
  3. [§5.1.4, Table 2] No statistical significance tests are provided. LLM outputs are non-deterministic, and the reported point estimates come from a single run. The abstract uses 'significantly higher accuracy,' but without multiple runs, confidence intervals, or a paired significance test, the differences (e.g., 80.34 vs. 39.01) could be overstated. I recommend repeating experiments with several seeds/prompts and reporting bootstrap confidence intervals or a paired test for Table 2 and Table 6.
  4. [§4.1, Figure 6, Table 5] Adaptive context generation assumes that a fully instrumented synthesized example produces an object graph similar enough to the target query state for in-context learning to transfer. This assumption is load-bearing: if the synthesized analog differs in control flow, library behavior, or alias patterns, the LLM may recover wrong values/structures, and the backward definition search fails. The ablation in Table 5 shows that in-context learning helps overall, but it does not test sensitivity to the relevance of the synthesized example. I recommend varying the similarity of the synthesized example (e.g., different data structures, library calls, or control flow) and showing how recovery accuracy changes.
minor comments (5)
  1. [Table 2 / §5.1.2] The benchmark name is inconsistent: 'LLM Generated Dataset' in Table 2 and 'Hierarchical Synthetic Dataset' in §5.1.2. Please use one consistent name throughout.
  2. [Figure 8] The two panels labeled 'Precision (%)' and 'Recall (%)' appear to show identical values for all bars. If this is intended because precision equals recall for RecovSlicing, please clarify; otherwise the figure likely contains a plotting error.
  3. [§5.1.3] For the ND-Slicer baseline, the paper states that any correct prediction among the top three yields 100% precision. This is a lenient evaluation for the baseline, so RecovSlicing's advantage is conservative. Please state this explicitly in the main text.
  4. [§5.4.2] The trace length limit of 100,000 steps and the 60-minute timeout are reasonable, but the selection of 489 of 835 bugs should be documented in more detail, including the distribution over projects and any resulting bias.
  5. [General] The reference [4] is an anonymous website; for reproducibility, provide a permanent artifact DOI or repository. Also remove the template line 'Received 20 February 2007...' at the end of the appendix.

Circularity Check

0 steps flagged

No significant circularity; the derivation is an empirically evaluated LLM-estimation pipeline with independent ground truth.

full rationale

RecovSlicing's chain is: partial trace + code -> LLM variable recovery -> alias inference -> backward definition search. The output (definition step) is not an input to any fitted parameter, and no equation defines the prediction in terms of the target. The adaptive prompt provides a fully instrumented analogous example, but the target object graph is not copied from it; the LLM must still infer target values and structure, and RQ2 validates recovery against exhaustive instrumentation. The main concern—the Hierarchical Synthetic Dataset is LLM-generated (§5.1.2), raising possible training-data contamination—is a threat to external validity, not a circular reduction: the benchmark ground truth is execution-based, not derived from RecovSlicing's own outputs. The Defects4J application uses an external bug dataset, and the Tregression baseline, though from overlapping authors, is not invoked as a uniqueness theorem or as load-bearing justification for the method's correctness. No exhibited Eq. X = Eq. Y, no fitted parameter renamed as prediction, and no self-citation chain forces the result. Under the strict exhibit-the-reduction rule, there is no circularity.

Axiom & Free-Parameter Ledger

4 free parameters · 4 axioms · 0 invented entities

The approach rests on the trustworthiness of LLM inference over program state, plus a few configuration thresholds. There are no fitted parameters or newly postulated physical entities. The main epistemic debt is the representativeness of the synthesized in-context example.

free parameters (4)
  • code_size_threshold_t = user-defined threshold (not specified numerically)
    Controls the size of the synthesized code example in adaptive context generation; chosen by user, not fitted to data.
  • instrumentation_depth = one layer deep (RQ4)
    In the Defects4J experiment, instrumentation records variables up to one layer deep; this choice affects the partial trace content.
  • trace_length_limit = 100,000 steps
    Used in RQ4 to cap trace length; a configuration choice.
  • timeout = 60 minutes
    Debugging sessions exceeding 60 min are counted as failed; this affects the success rate.
axioms (4)
  • domain assumption LLM can infer runtime variable values and object graph structure from the partial trace and code context
    Central to variable recovery; if the LLM hallucinates values, dependencies are wrong. The paper provides failure examples (e.g., WeakHashMap table index).
  • ad hoc to paper The synthesized code example's fully instrumented object graph is representative enough for in-context learning
    Used in adaptive context generation; no guarantee of representativeness across library behaviors or alias patterns.
  • domain assumption Application-level trace plus source code contains enough information to recover query variable aliases
    Partial trace only records application code; the query variable may live deeply inside library objects, and alias recovery depends on LLM judgment.
  • domain assumption Exhaustive instrumentation on moderate-size programs yields a reliable ground-truth full trace for evaluation
    The evaluation uses full instrumentation to obtain ground truth for the RQ2 component analysis; this is only feasible for small programs and may not generalize.

reviewed 2026-08-05 · how reviews work

0 comments
Cite this review

Pith. "Pith review of LLM as an Execution Estimator: Recovering Missing Dependency for Practical Time-travelling Debugging." pith.science (2026). https://pith.science/paper/DAUC2RLI

@misc{pith2026250818721,
  author       = {Pith},
  title        = {Pith review of: LLM as an Execution Estimator: Recovering Missing Dependency for Practical Time-travelling Debugging},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DAUC2RLI}},
  note         = {Machine review of arXiv:2508.18721}
}
Share X Bluesky LinkedIn Reddit HN
abstract

Determining the dynamic data dependency of a step that reads a variable $v$ is challenging. It typically requires either exhaustive instrumentation, which becomes prohibitively expensive when $v$ is defined within library calls, or repeated executions, which are impractical for non-deterministic programs. In this work, we propose RecovSlicing for computing dynamic data dependency in a single run, with only partial instrumentation. We explore the intuition that LLM can potentially infer program dynamics based on a partially recorded trace and relevant code as its context. Given (1) a partially recorded trace of a program $P$ and (2) the slicing criteria consisting of a query step $s$ and a query variable $v$ read by $s$, RecovSlicing computes the runtime definition of $v$ on the trace by estimating the miss-recorded execution of $P$. In this work, we allow the user to specify implicit query variable. Technically, built upon non-deterministic LLM, we address the challenges of (1) precise recovery of runtime variable value and structure from the recorded execution and (2) aligning the memory address of recovered variables and the recorded variables for definition analysis. We evaluate RecovSlicing on 8300 data dependencies across three slicing benchmarks, comparing it with Slicer4J, ND-Slicer, LLM Slicer, and re-execution Slicer. RecovSlicing achieves significantly higher accuracy (80.3%, 91.1%, 98.3%) and recall (up to 98.3%) than the best baseline (accuracy: 39.0%, 82.0%, 59.9%; recall: 53.4%, 79.1%, 87.1%). Integrated into a dual-slicing regression bug localizer, it identifies 16% more regressions.

Figures

Figures reproduced from arXiv: 2508.18721 by Hongshu Wang, Jin Song Dong, Weiyu Kong, Wenjie Zhang, Yun Lin, Yunrui Pei.

Figure 1
Figure 1. Figure 1: A simplified code example for computing dynamic data dependency. The query step is on line 13 and query variable [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The dynamics of the code in Figure 1, assuming [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 5
Figure 5. Figure 5: Overview of variable recovery with adaptive in [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗
Figure 4
Figure 4. Figure 4: The format of query variable instance, which is an [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 6
Figure 6. Figure 6: A synthesized code example for adaptive example, [PITH_FULL_IMAGE:figures/full_fig_p006_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Run the motivating example using the algorithm. The query step is on line 13, and the query variable is [PITH_FULL_IMAGE:figures/full_fig_p007_7.png] view at source ↗
Figure 9
Figure 9. Figure 9: Code snippets from Hierarchical Synthetic Dataset. [PITH_FULL_IMAGE:figures/full_fig_p009_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: The debugging agent used in this experiment. [PITH_FULL_IMAGE:figures/full_fig_p010_10.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

61 extracted references · 50 canonical work pages · 3 internal anchors

  1. [1]

    Hiralal Agrawal, Richard A DeMillo, and Eugene H Spafford. 1993. Debugging with dynamic slicing and backtracking. Software: Practice and Experience 23, 6 (1993), 589–616

  2. [2]

    Hiralal Agrawal and Joseph R Horgan. 1990. Dynamic program slicing. ACM SIGPlan Notices 25, 6 (1990), 246–256

  3. [3]

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

  4. [4]

    Anonymous. 2025. Anonymous Website for Recov-Slicing. https://sites.google. com/view/recov-slicing/home

  5. [5]

    Earl T Barr and Mark Marron. 2014. Tardis: Affordable time-travel debugging in managed runtimes. ACM SIGPLAN Notices 49, 10 (2014), 67–82

  6. [6]

    David Binkley. 1998. The application of program slicing to regression testing. Information and software technology 40, 11-12 (1998), 583–594

  7. [7]

    Gerardo Canfora, Aniello Cimitile, and Andrea De Lucia. 1998. Conditioned program slicing. Information and Software Technology 40, 11-12 (1998), 595–607

  8. [8]

    Oscar Chaparro, Carlos Bernal-Cárdenas, Jing Lu, Kevin Moran, Andrian Marcus, Massimiliano Di Penta, Denys Poshyvanyk, and Vincent Ng. 2019. Assessing the quality of the steps to reproduce in bug reports. In Proceedings of the 2019 27th Conference acronym ’XX, June 03–05, 2018, Woodstock, NY Trovato et al. ACM joint meeting on european software engineerin...

  9. [9]

    Yangruibo Ding, Benjamin Steenhoek, Kexin Pei, Gail Kaiser, Wei Le, and Baishakhi Ray. 2024. Traced: Execution-aware pre-training for source code. In Proceedings of the 46th IEEE/ACM International Conference on Software Engi- neering. 1–12

  10. [10]

    Qingxiu Dong, Lei Li, Damai Dai, Ce Zheng, Jingyuan Ma, Rui Li, Heming Xia, Jingjing Xu, Zhiyong Wu, Tianyu Liu, et al. 2022. A survey on in-context learning. arXiv preprint arXiv:2301.00234 (2022)

  11. [11]

    Angela Fan, Beliz Gokkaya, Mark Harman, Mitya Lyubarskiy, Shubho Sengupta, Shin Yoo, and Jie M Zhang. 2023. Large language models for software engineering: Survey and open problems. In2023 IEEE/ACM International Conference on Software Engineering: Future of Software Engineering (ICSE-FoSE) . IEEE, 31–53

  12. [12]

    Chongzhou Fang, Ning Miao, Shaurya Srivastav, Jialin Liu, Ruoyu Zhang, Ruijie Fang, Ryan Tsang, Najmeh Nazari, Han Wang, Houman Homayoun, et al. 2024. Large language models for code analysis: Do{LLMs} really do their job?. In 33rd USENIX Security Symposium (USENIX Security 24) . 829–846

  13. [13]

    Rajiv Gupta and Mary Lou Soffa. 1995. Hybrid slicing: An approach for refining static slices using dynamic information. ACM SIGSOFT Software Engineering Notes 20, 4 (1995), 29–40

  14. [14]

    Robert J Hall. 1995. Automatic extraction of executable program subsets by simultaneous dynamic program slicing. Automated Software Engineering 2 (1995), 33–53

  15. [15]

    Mark Harman and Sebastian Danicic. 1995. Using program slicing to simplify testing. Software Testing, Verification and Reliability 5, 3 (1995), 143–162

  16. [16]

    Mingyuan Huang, Jiachi Chen, Zigui Jiang, and Zibin Zheng. 2024. Revealing hidden threats: An empirical study of library misuse in smart contracts. In Pro- ceedings of the 46th IEEE/ACM International Conference on Software Engineering . 1–12

  17. [17]

    Raisa Islam and Owana Marzia Moushi. 2024. Gpt-4o: The cutting-edge advance- ment in multimodal llm. Authorea Preprints (2024)

  18. [18]

    Wei Jin and Alessandro Orso. 2012. Bugredux: Reproducing field failures for in-house debugging. In 2012 34th international conference on software engineering (ICSE). IEEE, 474–484

  19. [19]

    Noah M Johnson, Juan Caballero, Kevin Zhijie Chen, Stephen McCamant, Pongsin Poosankam, Daniel Reynaud, and Dawn Song. 2011. Differential slicing: Identify- ing causal execution differences for security applications. In2011 IEEE Symposium on Security and Privacy . IEEE, 347–362

  20. [20]

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

  21. [21]

    Sungmin Kang, Juyeon Yoon, Nargiz Askarbekkyzy, and Shin Yoo. 2024. Evaluat- ing diverse large language models for automatic and general bug reproduction. IEEE Transactions on Software Engineering (2024)

  22. [22]

    Bogdan Korel and Janusz Laski. 1988. Dynamic program slicing. Information processing letters 29, 3 (1988), 155–163

  23. [23]

    Rahul Krishna, Rangeet Pan, Raju Pavuluri, Srikanth Tamilselvam, Maja Vukovic, and Saurabh Sinha. 2024. Codellm-Devkit: A Framework for Contextualizing Code LLMs with Program Analysis Insights. arXiv preprint arXiv:2410.13007 (2024)

  24. [24]

    Kun Kuang, Ruoxuan Xiong, Peng Cui, Susan Athey, and Bo Li. 2020. Stable pre- diction with model misspecification and agnostic distribution shift. InProceedings of the AAAI Conference on Artificial Intelligence , Vol. 34. 4485–4492

  25. [25]

    LeetCode. [n. d.]. LeetCode. https://leetcode.com/

  26. [26]

    Anatole Lefort, Yohan Pipereau, Kwabena Amponsem, Pierre Sutra, and Gaël Thomas. 2021. J-NVM: off-heap persistent objects in java. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles . 408–423

  27. [27]

    Haonan Li, Yu Hao, Yizhuo Zhai, and Zhiyun Qian. 2024. Enhancing static analysis for practical bug detection: An llm-integrated approach. Proceedings of the ACM on Programming Languages 8, OOPSLA1 (2024), 474–499

  28. [28]

    Xiangyu Li and Alessandro Orso. 2020. More accurate dynamic slicing for better supporting software debugging. In 2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST). IEEE, 28–38

  29. [29]

    Xinbin Liang, Zhuoxuan Liu, Jie Wang, Xinqiao Jin, and Zhimin Du. 2023. Un- certainty quantification-based robust deep learning for building energy systems considering distribution shift problem. Applied Energy 337 (2023), 120889

  30. [30]

    Yun Lin, Jun Sun, Yinxing Xue, Yang Liu, and Jinsong Dong. 2017. Feedback- based debugging. In 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE). IEEE, 393–403

  31. [31]

    Wei Ma, Shangqing Liu, Zhihao Lin, Wenhan Wang, Qiang Hu, Ye Liu, Cen Zhang, Liming Nie, Li Li, and Yang Liu. 2023. Lms: Understanding code syntax and semantics for code analysis. arXiv preprint arXiv:2305.12138 (2023)

  32. [32]

    Jens Meinicke, Chu-Pan Wong, Christian Kästner, and Gunter Saake. 2018. Un- derstanding differences among executions with variational traces. arXiv preprint arXiv:1807.03837 (2018)

  33. [33]

    Mohammad Mahdi Mohajer, Reem Aleithan, Nima Shiri Harzevili, Moshi Wei, Alvine Boaye Belle, Hung Viet Pham, and Song Wang. 2024. Effectiveness of chat- gpt for static analysis: How far are we?. InProceedings of the 1st ACM International Conference on AI-Powered Software. 151–160

  34. [34]

    Akira Nishimatsu, Minoru Jihira, Shinji Kusumoto, and Katsuro Inoue. 1999. Call- mark slicing: An efficient and economical way of reducing slice. In Proceedings of the 21st international conference on Software engineering . 422–431

  35. [35]

    Vijay Krishna Palepu, Guoqing Xu, and James A Jones. 2013. Improving efficiency of dynamic analysis with dynamic dependence summaries. In2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE) . IEEE, 59–69

  36. [36]

    Vijay Krishna Palepu, Guoqing Xu, and James A Jones. 2017. Dynamic dependence summaries. ACM Transactions on Software Engineering and Methodology (TOSEM) 25, 4 (2017), 1–41

  37. [37]

    Mohammad M Rahman, Foutse Khomh, and Marco Castelluccio. 2022. Works for me! cannot reproduce–a large scale empirical study of non-reproducible bugs. Empirical Software Engineering 27, 5 (2022), 111

  38. [38]

    Kimya Khakzad Shahandashti, Mohammad Mahdi Mohajer, Alvine Boaye Belle, Song Wang, and Hadi Hemmati. 2024. Program Slicing in the Era of Large Language Models. arXiv preprint arXiv:2409.12369 (2024)

  39. [39]

    Josep Silva. 2012. A vocabulary of program slicing-based techniques. ACM computing surveys (CSUR) 44, 3 (2012), 1–41

  40. [40]

    William N Sumner and Xiangyu Zhang. 2013. Comparative causality: Explaining the differences between executions. In 2013 35th International Conference on Software Engineering (ICSE). IEEE, 272–281

  41. [41]

    Amjed Tahir, Shawn Rasheed, Jens Dietrich, Negar Hashemi, and Lu Zhang. 2023. Test flakiness’ causes, detection, impact and responses: A multivocal review. Journal of Systems and Software 206 (2023), 111837

  42. [42]

    Hugo Touvron, Louis Martin, Kevin Stone, Peter Albert, Amjad Almahairi, Yas- mine Babaei, Nikolay Bashlykov, Soumya Batra, Prajjwal Bhargava, Shruti Bhos- ale, et al. 2023. Llama 2: Open foundation and fine-tuned chat models. arXiv preprint arXiv:2307.09288 (2023)

  43. [43]

    Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. 2017. Attention is all you need. Advances in neural information processing systems 30 (2017)

  44. [44]

    Guda A Venkatesh. 1991. The semantic approach to program slicing. In Proceed- ings of the ACM SIGPLAN 1991 conference on Programming language design and implementation. 107–119

  45. [45]

    Chengpeng Wang, Yifei Gao, Wuqi Zhang, Xuwei Liu, Qingkai Shi, and Xiangyu Zhang. 2024. LLMSA: A Compositional Neuro-Symbolic Ap- proach to Compilation-free and Customizable Static Analysis. arXiv preprint arXiv:2412.14399 (2024)

  46. [46]

    Di Wang, Matthias Galster, and Miguel Morales-Trujillo. 2024. A systematic mapping study of bug reproduction and localization. Information and Software Technology 165 (2024), 107338. doi:10.1016/j.infsof.2023.107338

  47. [47]

    Haijun Wang, Yun Lin, Zijiang Yang, Jun Sun, Yang Liu, Jinsong Dong, Qinghua Zheng, and Ting Liu. 2019. Explaining regressions via alignment slicing and mending. IEEE Transactions on Software Engineering 47, 11 (2019), 2421–2437

  48. [48]

    Jiayimei Wang, Tao Ni, Wei-Bin Lee, and Qingchuan Zhao. 2025. A Contemporary Survey of Large Language Model Assisted Program Analysis. arXiv preprint arXiv:2502.18474 (2025)

  49. [49]

    Tao Wang and Abhik Roychoudhury. 2007. Hierarchical dynamic slicing. In Proceedings of the 2007 international symposium on Software testing and analysis . 228–238

  50. [50]

    Dasarath Weeratunge, Xiangyu Zhang, William N Sumner, and Suresh Jagan- nathan. 2010. Analyzing concurrency bugs using dual slicing. In Proceedings of the 19th international symposium on Software testing and analysis . 253–264

  51. [51]

    M WEISER. 1984. Program slicing. IEEE transactions on software engineering 10, 4 (1984), 352–357

  52. [52]

    Baowen Xu, Ju Qian, Xiaofang Zhang, Zhongqiang Wu, and Lin Chen. 2005. A brief survey of program slicing. ACM SIGSOFT Software Engineering Notes 30, 2 (2005), 1–36

  53. [53]

    Aashish Yadavally, Yi Li, and Tien N Nguyen. 2024. Predictive Program Slicing via Execution Knowledge-Guided Dynamic Dependence Learning. Proceedings of the ACM on Software Engineering 1, FSE (2024), 271–292

  54. [54]

    Aashish Yadavally, Tien N Nguyen, Wenbo Wang, and Shaohua Wang. 2023. (Partial) Program Dependence Learning. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 2501–2513

  55. [55]

    Junjie Ye, Xuanting Chen, Nuo Xu, Can Zu, Zekai Shao, Shichun Liu, Yuhan Cui, Zeyang Zhou, Chao Gong, Yang Shen, et al. 2023. A comprehensive capability analysis of gpt-3 and gpt-3.5 series models.arXiv preprint arXiv:2303.10420 (2023)

  56. [56]

    Xiangyu Zhang and Rajiv Gupta. 2004. Cost effective dynamic program slicing. ACM SIGPLAN Notices 39, 6 (2004), 94–106

  57. [57]

    Xiangyu Zhang, Rajiv Gupta, and Youtao Zhang. 2005. Cost and precision tradeoffs of dynamic data slicing algorithms. ACM Transactions on Programming Languages and Systems (TOPLAS) 27, 4 (2005), 631–661

  58. [58]

    toString

    Xiangyu Zhang, Sriraman Tallam, and Rajiv Gupta. 2006. Dynamic slicing long running programs through execution fast forwarding. In Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering . 81–91. LLM as an Execution Estimator: Recovering Missing Dependency for Practical Time-travelling Debugging Conference acrony...

  59. [59]

    You will receive a **target line of code**

  60. [60]

    You will also be given a **variable name** and the **line of code** where this variable is used

  61. [61]

    ccc", "xyz

    Your objective is to determine whether the target line writes to the specified variable. ### Response Format: Please provide a clear answer based on your analysis: - **Answer: <T>** (True) if the target line writes to the variable. - **Answer: <F>** (False) if it does not. ### Examples: **Example 1:** - **h** is an `ArrayList` - **Target Line:** `h.set(10...

This paper was first reviewed by deepseek-v4-flash on August 5, 2026.