Pith. sign in

REVIEW 5 major objections 5 minor 67 references

Guided Debugging of Auto-Translated Code Using Differential Testing

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

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

Pith's one-line read Tool pinpoints LLM translation errors, cutting manual review lines by 71%.

desk verdict Practical new debugging tool for LLM-translated code, but the evaluation does not yet prove that the flagged lines are the faulty ones; needs baselines and ground-truth metrics. read the letter →

arxiv 2501.09475 v1 pith:EXR3RWQM submitted 2025-01-16 cs.SE

Shengnan Wu , Xinyu Sun , Xin Wang , Yangfan Zhou This is my paper · ORCID
classification cs.SE
keywords codetranslationdifferentialtestingcoverage-guidedfuzzingfaultlocalizationLLMdebuggingsuggestionsauto-translated
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 translation errors in code automatically translated by large language models can be located automatically, rather than by line-by-line human inspection. The authors propose tHinter, which fuzzes the translated code to generate diverse test cases, runs those inputs through both the source and translated programs, and flags the translated lines whose execution correlates with mismatched outputs. On 211 Python-to-C++ translations from LeetCode solutions, tHinter reduced the lines a developer must review by 71% on average, and it raised the chance that a single LLM repair prompt fixes the error by 59%. The paper's core thesis is that lines causing output differences are closely related to translation errors, and that this ordinary software-testing insight is enough to make LLM-translated code debuggable.

What carries the argument

tHinter is a pipeline of three steps: coverage-guided fuzzing to generate test cases until 90% line coverage or a one-minute fallback; differential testing that compares source and translated outputs to mark each test case pass or fail; and a localization algorithm that assigns each translated line a suspicious score. The score combines a statistics component, which calculates the conditional probability of a line being incorrectly translated from its coverage pattern across passing and failing test cases (Heuristics 1 and 2), and an expertise component encoding five developer-derived heuristics, such as control-flow code being more error-prone. Lines whose combined score exceeds a threshold, or two standard deviations above the mean when no line exceeds the threshold, are returned as the debugging suggestion.

What would settle it

Take a pair of source and translated programs, deliberately introduce a translation error in a rarely executed branch, and constrain the fuzzer's input space so that coverage stays below the branch when the one-minute fallback stops fuzzing. If tHinter fails to flag the faulty line because no failing test case covers it, that is direct evidence that the 90% coverage or one-minute stop condition does not guarantee error localization.

Watch

Extended reading notes

Core claim

tHinter establishes that the task of locating translation errors in auto-translated code can be formulated as differential testing: because a correct translation must produce identical outputs to the source for every input, any line in the translated code whose execution coincides with an output mismatch is a candidate translation error. The paper's discovery is that a coverage-guided fuzzer can supply the diverse test cases needed, and a heuristic score blending conditional probabilities with developer-experience rules can turn pass/fail results into a ranked list of suspicious lines. The result is a debugging suggestion that reduced manual review by 71% and improved single-query LLM fix rate by 59% in the paper's experiments.

Load-bearing premise

The whole approach rests on the fuzzer managing to generate at least one test case that executes the mistranslated line; if the error-triggering input is never reached, tHinter cannot flag that line, and its reduction and fix-rate gains vanish.

Editorial extensions

If this is right

  • Developers debugging auto-translated code without other tools can focus on an average of 29% of the lines, because tHinter's suggestions exclude the rest.
  • When LLMs are used to fix the code, providing tHinter's localized lines as context raises the single-query fix success rate from roughly 0.27 to 0.43, a 59% relative increase.
  • The perceived quality of LLM-produced fixes improves by 13% on average, with low-complexity code benefiting most (40%).
  • Executing more test cases improves localization; dropping to 50 test cases significantly lowers perceived helpfulness, confirming that coverage-guided generation is load-bearing.
  • Low-complexity translated code gets the highest line-reduction ratio, suggesting that well-structured code is easier for the statistics to exclude correctly translated lines.

Reading between the lines

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

  • The same pipeline should transfer to other LLVM-supported language pairs (for example, Java to Rust), because neither the fuzzing nor the coverage analysis depends on Python or C++ specifics, though the expertise heuristics may need recalibration for other language idioms.
  • The localized lines could seed automated program repair rather than only a suggestion to humans or LLMs, since the fix-rate gains show that pointing at the right context is the bottleneck.
  • Because the method flags lines by correlation with failing tests, it may also localize bugs in any pair of programs that should be functionally equivalent, such as refactored code or a reimplementation of the same specification.
  • A testable extension is to compare tHinter's ranking against pure spectrum-based fault localization (for example, the Ochiai formula) on the same dataset to measure how much signal the developer-expertise heuristics add beyond statistical correlation.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

5 major / 5 minor

Summary. The paper proposes tHinter, a tool that localizes translation errors in LLM-translated code (Python to C++). tHinter uses AFL++ to generate test cases for the translated code, runs the same inputs through the source and translated code under a differential-testing oracle, and produces a ranked set of suspicious lines using a heuristic score that combines coverage/failure statistics (Algorithm 1) with syntax-based expertise heuristics (Algorithm 2). The evaluation on 211 LeetCode-derived code pairs reports a 71% average reduction in lines needing manual review (R_reduc), a perceived helpfulness score of 3.18/5, a 59% relative increase in GPT-3.5 single-query fix rate, and a 13% increase in perceived fix quality. Two case studies illustrate the flagged lines for a chained-comparison semantic error and an integer-overflow error.

Significance. The differential-testing oracle is a sound, non-circular basis for detecting translation errors, and the paper addresses a real pain point: LLM-translated code lacks explainability and is hard to debug. The tool concept—coverage-guided fuzzing plus failure-coverage heuristics—is reasonable and potentially useful. However, the current evidence does not yet demonstrate the central localization claim. R_reduc measures only the size of the suggestion, not whether it contains the faulty lines; the only direct evidence of localization quality is the two case studies. H_perceived and Q_fix are scored by the two author-conductors, and no baselines, controls, confidence intervals, or significance tests are provided. Algorithms 1 and 2 also omit essential definitions and parameter values. If the requested ground-truth evaluation and baselines are added, the paper would make a credible contribution.

major comments (5)
  1. [§3.3, Algorithms 1 and 2] Algorithm 1 is under-specified and cannot be re-implemented. The score is written as `suspiciousScoreByStatistics = baseScore + P(np/nf) * θ_punish`, but `np` and `nf` are never defined, and `P(np/nf)` is never given a functional form; consequently, Heuristics 1 and 2 are not actually operationalized. Algorithm 2 is similarly incomplete: `susceptibleSyntaxUnit` is initialized as an empty set and never populated, `analyzeSyntaxByLine` is undefined, and the update `suspiciousScoreByExpertise = suspiciousScore + α1` appears to be a typo. The values of `baseScore`, `θ_punish`, `α1`, `α2`, and the flag threshold are not reported anywhere. Please define the probability model, the syntax-analysis rules, and all parameter values, and describe how the parameters were chosen.
  2. [§4.2, Eq. (4), §4.1.3] The headline R_reduc metric is not a measure of localization quality. Eq. (4) defines R_reduc as 1 − Len(localized)/Len(translated), so it is high for any method that returns a small number of lines, regardless of whether those lines contain translation errors; a random subset of the same size would achieve a similar R_reduc. The paper reports no precision, recall, or ranking accuracy against known erroneous lines, and it does not compare against existing fault-localization baselines (e.g., spectrum-based methods or a random-lines baseline). H_perceived is also scored by the two author-conductors with no inter-rater agreement statistic. Please add a ground-truth evaluation on annotated error lines and at least a random-lines or SBFL baseline.
  3. [§4.3, Fig. 6] The RQ2 experiment cannot separate the effect of localization from the effect of any extra hint. The `with tHinter` prompt includes the localized lines and the task description, while the `without tHinter` prompt omits all such context; thus the 59% fix-rate gain could be produced by a generic `the code contains translation errors` message or by any equally sized set of candidate lines. A control condition with random lines of the same size, or with a non-localizing hint, is required to support the claim that the ranking is what helps. In addition, Dataset B has only 30 pairs, and no confidence intervals or significance tests are reported for R_fix, R_attp, or Q_fix.
  4. [§3.1 and §4.4, Table 5] The paper's coverage story is not empirically supported. RQ3 concludes that more test cases improve performance, but Table 5 shows R_reduc = 0.71 for 10,000 cases, 0.73 for 200 cases, and 0.72 for 50 cases; only H_perceived drops at 50 cases. The paper also never reports what coverage was actually achieved per pair, or how often the one-minute fuzzing fallback was used instead of the 90% line-coverage stop condition. Since the whole mechanism depends on at least one failing test case exercising the faulty line, please report achieved coverage, the distribution of generated test-case counts, and a sensitivity analysis of R_reduc/R_fix with respect to coverage.
  5. [§4.1.1 and §6] The evaluation is based on 211 pairs generated by a single GPT-3.5 translation tool whose prompts were iteratively tuned by the authors, and the dataset is purposively sampled to emphasize runtime errors. No train/test split or parameter-selection procedure is described for the localization algorithm, so it is unclear whether the reported numbers are optimistic estimates. The paper acknowledges in Section 6 that performance may vary across translation tools, but the abstract and conclusion still make general claims. Please scope the claims to runtime-error cases in this translation pipeline, or add an evaluation on an independently produced dataset and an explicit validation procedure for the algorithm's parameters.
minor comments (5)
  1. [§2, §5.2, §3.1, §7.3] There are numerous typos and grammatical slips: `an debugging suggestion` (§2), `minimum spped` (§5.2), `filer` for `filter` (§3.1), and `comparation` for `comparison` (§7.3); please proofread the manuscript.
  2. [§3.1] The source of seeds for AFL++ is never explained. The input to tHinter is said to include `seeds, i.e., example inputs of the translated code`, but the paper does not say how these are obtained or whether they are available for all tasks; this is needed for reproducibility.
  3. [§1 and §8] The paper states that tHinter will be released as open source and later says `we open source tHinter`, but no repository URL or artifact instructions are provided. Please include a link or supplementary artifact.
  4. [§7.2] The related-work section on debugging would benefit from a brief discussion of spectrum-based fault localization, since it is the most natural baseline for the proposed scoring approach.
  5. [Header and references] The manuscript metadata contains placeholders (e.g., the conference acronym, `June 03–05, 2018`, and the DOI stub), and several reference entries have stray punctuation; these should be cleaned before submission.

Circularity Check

1 steps flagged · score 6.0 of 10

The headline 71% reduction is a definitional restatement of tHinter's output size; partial circularity, but R_fix evidence is external.

  1. self definitional [Section 4.1.2 (Eq. 4) and Section 4.2 (RQ1 result)]
    "R_reduc measures the ratio of lines excluded by tHinter, and is calculated as: R_reduc = 1 - Len(localized)/Len(translated) (4) ... the average R_reduc is 0.71, meaning that, on average, 71% of the code no longer requires manual inspection."

    The claimed outcome 'lines no longer require manual inspection' is defined by Eq. 4 as the complement of the length of tHinter's own debugging suggestion. The reported 0.71 is therefore a restatement of the size of Len(localized) relative to Len(translated), not a measurement of whether the excluded lines are correctly translated or whether the retained lines contain translation errors. Any suggestion-producing method that returns a small line set, including a random or trivial one, achieves the same R_reduc by construction. The metric is thus self-definitional with respect to the headline localization claim.

full rationale

The core differential-testing mechanism is externally grounded: Eq. 1 defines pass/fail by comparing source and translated outputs on fuzzed inputs, and coverage-guided fuzzing is an independent component. There is no load-bearing self-citation; the only overlapping reference (Muffin, ref [25]) is background on fuzzing deep-learning libraries. The R_fix and R_attp metrics are external behavioral measures of LLM repair attempts and successes, and the two case studies provide anecdotal evidence that the flagged lines can be the faulty ones. The circularity is confined to the headline R_reduc claim: Eq. 4 computes the reduction directly from the size of tHinter's own output, so the 71% number carries no information about localization accuracy. Separately, H_perceived is scored by the two author-conductors and no precision/recall against known error lines is reported; these are validity concerns rather than additional circular steps. Overall, partial circularity: one headline prediction reduces by construction, while other evidence remains independent.

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

The paper introduces no new theoretical entities. The central claim rests on domain assumptions about fuzzing coverage, the differential testing oracle, and the validity of hand-derived debugging heuristics. The algorithm contains several unreported hyperparameters that may be fitted to the evaluation data.

free parameters (5)
  • theta_punish
    Weight in Algorithm 1 balancing Heuristic 1 and Heuristic 2. Value not reported.
  • baseScore
    Regularization term in Algorithm 1 to avoid negative scores. Value not reported.
  • alpha_1
    Additive weight for suspicious syntax units in Algorithm 2. Value not reported.
  • alpha_2
    Multiplicative weight for suspicious syntax scopes in Algorithm 2. Value not reported.
  • flag threshold
    Threshold for flagging suspicious lines; unspecified, with anomaly detection fallback.
assumptions (5)
  • domain assumption Correctly translated code gives the same output as source for the same input
    Basis of the differential testing oracle, Eq. 1 in Section 3.2.
  • domain assumption Coverage-guided fuzzing with 90% line coverage stop condition sufficiently exercises error-relevant behavior
    Section 3.1 stop condition; if errors are not covered, localization fails.
  • ad hoc to paper Lines covered by failing differential tests are likely translation errors (Heuristics 1 and 2)
    Core statistical assumption in Algorithm 1, not proven.
  • ad hoc to paper Control flow, type-specific code, and structurally simple code have different translation error-proneness (Heuristics 3 to 5)
    Derived from a 40-minute round table with three developers, Section 3.3.
  • domain assumption GPT-3.5 with in-context examples is a representative translation tool
    Used to build the evaluation dataset, Section 4.1.1; results may not generalize.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Guided Debugging of Auto-Translated Code Using Differential Testing." pith.science (2026). https://pith.science/paper/EXR3RWQM

@misc{pith2026250109475,
  author       = {Pith},
  title        = {Pith review of: Guided Debugging of Auto-Translated Code Using Differential Testing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EXR3RWQM}},
  note         = {Machine review of arXiv:2501.09475}
}
read the original abstract

Large Language Models (LLMs) hold great promise in the task of code translation. However, the lack of explainability complicates the identification of the inevitable translation errors. In this paper, we propose tHinter, a debugging tool to locate translation errors in auto-translated code. The core idea of tHinter is that correctly translated, the source and translated code should present the same functionalities, giving the same output for the same input. Hence, lines in the translated code responsible for output differences are possibly translation errors. First, tHinter employs fuzzing to generate diverse test cases that thoroughly explore the translated code. Then, tHinter relies on a heuristic algorithm to pinpoint translation errors from coverage information and differential testing execution results of those test cases. This heuristic algorithm is designed to leverage both the statistics and the expertise of developers. Comprehensive experiments with real code show its effectiveness. It reduces 71% lines developers need to review during debugging and increases the likelihood of the LLM fixing translation errors in a single query by 59%. Developers generally consider it satisfactory and helpful.

Figures

Figures reproduced from arXiv: 2501.09475 by the authors.

Figure 1
Figure 1. A Python Solution of Longest Palindrome Substring and the Auto-translated C++ Version Findings from the preliminary debugging experiment emphasize the importance of an debugging suggestion that highlights potential translation errors. Moreover, our exploration with Stack Overflow 4 illustrates that relying on manual replies from others is not a reliable way to obtain such suggestions. We searched with the tag "[code… view at source ↗
Figure 2
Figure 2. tHinter includes three steps: 1) fuzzing based test case generation, 2) differential testing execution, and 3) translation error localization [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. A simplified demonstration of the prompt used in the translation step. [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: A simplified demonstration of the prompt used in the validation step. [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: tHinter’s Performance Evaluated by 𝑅𝑟𝑒𝑑𝑢𝑐 . tHinter presents an average of 3.18 in 𝐻𝑝𝑒𝑟𝑐𝑒𝑖𝑣𝑒𝑑 , the place between Helpful and Quite helpful. This indicates developers are generally satisfied and consider tHinter effective. 𝐻𝑝𝑒𝑟𝑐𝑒𝑖𝑣𝑒𝑑 for each complexity group remains s…
Figure 6
Figure 6. Figure 6: Fixing translation errors by the LLM with/without tHinter. [PITH_FULL_IMAGE:figures/full_fig_p014_6.png]
Figure 7
Figure 7. Figure 7: Comparing of 𝑄𝑓 𝑖𝑥 with/without tHinter during debugging by the LLM. 4.4 Performance with Different Numbers of Test Cases Executed (RQ3) Baselines. We evaluate the key component of tHinter, the test case generation, by comparing the performance of tHinter with differen…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

67 extracted references · 31 canonical work pages

  1. [1]

    Karan Aggarwal, Mohammad Salameh, and Abram Hindle. 2015. Using machine translation for converting Python 2 to Python 3 code. PeerJ Prepr. 3 (2015), e1459. https://doi.org/10.7287/PEERJ.PREPRINTS.1459V1

    work page doi:10.7287/peerj.preprints.1459v1 2015

  2. [2]

    Hiralal Agrawal. 1991. Towards automatic debugging of computer programs . Purdue University

    work page 1991

  3. [3]

    Keromytis, and Aggelos Kiayias

    George Argyros, Ioannis Stais, Suman Jana, Angelos D. Keromytis, and Aggelos Kiayias. 2016. SFADiff: Automated Evasion Attacks and Fingerprinting Using Black-box Differential Automata Learning. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security . ACM, Vienna Austria, 1690–1701. https://doi.org/10. 1145/2976749.2978383

    arXiv 2016

  4. [4]

    Mikhail Auguston, Clinton Jeffery, and Scott Underwood. 2002. A Framework for Automatic Debugging. In 17th IEEE International Conference on Automated Software Engineering (ASE 2002), 23-27 September 2002, Edinburgh, Scotland, UK . IEEE Computer Society, 217–222. https://doi.org/10.1109/ASE.2002.1115015

    work page Pith review arXiv 2002

  5. [5]

    Brenda S. Baker. 1995. On Finding Duplication and Near-Duplication in Large Software Systems. In 2nd Working Conference on Reverse Engineering, WCRE ’95, Toronto, Canada, July 14-16, 1995 , Linda M. Wills, Philip Newcomb, and Elliot J. Chikofsky (Eds.). IEEE Computer Society, 86–95. https://doi.org/10.1109/WCRE.1995.514697

    work page arXiv 1995

  6. [6]

    Binkley, Marcia Davis, Dawn J

    Dave W. Binkley, Marcia Davis, Dawn J. Lawrie, Jonathan I. Maletic, Christopher Morrell, and Bonita Sharif. 2013. The impact of identifier style on effort and comprehension. Empir. Softw. Eng. 18, 2 (2013), 219–276. https://doi.org/10. 1007/S10664-012-9201-4

    work page 2013

  7. [7]

    Frederick P Brooks. 1974. The mythical man-month. Datamation 20, 12 (1974), 44–52

    1974

  8. [8]

    Chad Brubaker, Suman Jana, Baishakhi Ray, Sarfraz Khurshid, and Vitaly Shmatikov. 2014. Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations. IEEE security & privacy 2014 (2014), 114–129

    work page 2014

Show all 67 references
  1. [9]

    David Brumley, Juan Caballero, Zhenkai Liang, and James Newsome. 2007. Towards Automatic Discovery of Deviations in Binary Implementations with Applications to Error Detection and Fingerprint Generation. In Proceedings of the 16th USENIX Security Symposium, Boston, MA, USA, Au...

    2007

  2. [10]

    Cristian Cadar, Daniel Dunbar, and Dawson R. Engler. 2008. KLEE: Unassisted and Automatic Generation of High- Coverage Tests for Complex Systems Programs. In 8th USENIX Symposium on Operating Systems Design and Imple- mentation, OSDI 2008, December 8-10, 2008, San Diego, Calif...

    2008

  3. [11]

    Steve Campbell, Melanie Greenwood, Sarah Prior, Toniele Shearer, Kerrie Walkem, Sarah Young, Danielle Bywaters, and Kim Walker. 2020. Purposive sampling: complex or simple? Research case examples. Journal of research in Nursing 25, 8 (2020), 652–661

    2020

  4. [12]

    Peter Chapman and David Evans. 2011. Automated black-box detection of side-channel vulnerabilities in web applications. In Proceedings of the 18th ACM Conference on Computer and Communications Security, CCS 2011, Chicago, Illinois, USA, October 17-21, 2011 , Yan Chen, George D...

    2011

  5. [13]

    Yuting Chen, Ting Su, Chengnian Sun, Zhendong Su, and Jianjun Zhao. 2016. Coverage-Directed Differential Testing of JVM Implementations. In Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation. ACM, Santa Barbara CA USA, 85–99. https...

    2016

  6. [14]

    Yuting Chen and Zhendong Su. 2015. Guided Differential Testing of Certificate Validation in SSL/TLS Implementations. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering . ACM, Bergamo Italy, 793–804. https://doi.org/10.1145/2786805.2786835 , Vo...

    2015

  7. [15]

    Shaoming Duan, Chuanyi Liu, Peiyi Han, Xiaopeng Jin, Xinyi Zhang, Xiayu Xiang, and Hezhong Pan. 2023. Fed-DNN- Debugger: Automatically Debugging Deep Neural Network Models in Federated Learning.Security and Communication Networks 2023, 1 (2023), 5968168

    2023

  8. [16]

    Christof Ebert and James Cain. 2016. Cyclomatic Complexity. IEEE Softw. 33, 6 (2016), 27–29. https://doi.org/10.1109/ MS.2016.147

    2016

  9. [17]

    Aryaz Eghbali and Michael Pradel. 2022. CrystalBLEU: Precisely and Efficiently Measuring the Similarity of Code. In 44th IEEE/ACM International Conference on Software Engineering: Companion Proceedings, ICSE Companion 2022, Pittsburgh, PA, USA, May 22-24, 2022 . ACM/IEEE, 341–...

    2022

  10. [18]

    Hasan Ferit Eniser, Hanliang Zhang, Cristina David, Meng Wang, Brandon Paulsen, Joey Dodds, and Daniel Kroening

  11. [19]

    Evans and Alberto Savoia

    Robert B. Evans and Alberto Savoia. 2007. Differential testing: a new approach to change detection. In Proceedings of the 6th joint meeting of the European Software Engineering Conference and the ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2007,...

    2007

  12. [20]

    Feathers

    Michael C. Feathers. 2004. Working Effectively with Legacy Code. In Extreme Programming and Agile Methods - XP/Agile Universe 2004, 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, August 15-18, 2004, Proceedings (Lecture Notes in Computer Science, Vol...

    2004 doi

  13. [21]

    2020.{AFL++}: Combining incremental steps of fuzzing research

    Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. 2020.{AFL++}: Combining incremental steps of fuzzing research. In 14th USENIX Workshop on Offensive Technologies (WOOT 20)

    2020

  14. [22]

    Peter Fritzson, Tibor Gyimóthy, Mariam Kamkar, and Nahid Shahmehri. 1991. Generalized Algorithmic Debugging and Testing. In Proceedings of the ACM SIGPLAN’91 Conference on Programming Language Design and Implementation (PLDI), Toronto, Ontario, Canada, June 26-28, 1991 , David...

    1991

  15. [23]

    John D Gannon. 1979. Human factors in software engineering. Computer 12, 12 (1979), 6–7

    1979

  16. [24]

    Yingqiang Ge, Wenyue Hua, Jianchao Ji, Juntao Tan, Shuyuan Xu, and Yongfeng Zhang. 2023. Openagi: When llm meets domain experts. arXiv preprint arXiv:2304.04370 (2023)

    2023 arXiv

  17. [25]

    Jiazhen Gu, Xuchuan Luo, Yangfan Zhou, and Xin Wang. 2022. Muffin: Testing Deep Learning Libraries via Neural Architecture Fuzzing. In 44th IEEE/ACM 44th International Conference on Software Engineering, ICSE 2022, Pittsburgh, PA, USA, May 25-27, 2022 . ACM, 1418–1430. https:/...

    2022

  18. [26]

    Qing Huang, Zhenyu Wan, Zhenchang Xing, Changjing Wang, Jieshan Chen, Xiwei Xu, and Qinghua Lu. 2023. Let’s Chat to Find the APIs: Connecting Human, LLM and Knowledge Graph through AI Chain. In 38th IEEE/ACM International Conference on Automated Software Engineering, ASE 2023,...

    2023

  19. [27]

    Jaewon Hur, Suhwan Song, Sunwoo Kim, and Byoungyoung Lee. 2022. SpecDoctor: Differential Fuzz Testing to Find Transient Execution Vulnerabilities. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communica- tions Security. ACM, Los Angeles CA USA, 1473–1487. ht...

    2022

  20. [28]

    Suman Jana and Vitaly Shmatikov. 2012. Abusing File Processing in Malware Detectors for Fun and Profit. In 2012 IEEE Symposium on Security and Privacy . IEEE, San Francisco, CA, 80–94. https://doi.org/10.1109/SP.2012.15

    2012 doi

  21. [29]

    Toshihiro Kamiya, Shinji Kusumoto, and Katsuro Inoue. 2002. CCFinder: A Multilinguistic Token-Based Code Clone Detection System for Large Scale Source Code. IEEE Trans. Software Eng. 28, 7 (2002), 654–670. https: //doi.org/10.1109/TSE.2002.1019480

    2002 arXiv

  22. [30]

    Svetoslav Karaivanov, Veselin Raychev, and Martin T. Vechev. 2014. Phrase-Based Statistical Translation of Pro- gramming Languages. In Onward! 2014, Proceedings of the 2014 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming & Software, part...

    2014

  23. [31]

    Ko, Brad A

    Amy J. Ko, Brad A. Myers, Michael J. Coblenz, and Htet Htet Aung. 2006. An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks. IEEE Trans. Software Eng. 32, 12 (2006), 971–987. https://doi.org/10.1109/TSE.2006.116

    2006 doi

  24. [32]

    Philipp Koehn, Hieu Hoang, Alexandra Birch, Chris Callison-Burch, Marcello Federico, Nicola Bertoldi, Brooke Cowan, Wade Shen, Christine Moran, Richard Zens, Chris Dyer, Ondrej Bojar, Alexandra Constantin, and Evan Herbst. 2007. Moses: Open Source Toolkit for Statistical Machi...

    2007

  25. [33]

    Charles W Krueger. 1992. Software reuse. ACM Computing Surveys (CSUR) 24, 2 (1992), 131–183. , Vol. 1, No. 1, Article . Publication date: January 2018. Guided Debugging of Auto-Translated Code Using Differential Testing 21

    1992

  26. [34]

    Galindo, and Thi Ngoc Trang Tran

    Viet Man Le, Alexander Felfernig, Mathias Uta, David Benavides, José A. Galindo, and Thi Ngoc Trang Tran. 2021. DIRECTDEBUG: Automated Testing and Debugging of Feature Models. In 43rd IEEE/ACM International Conference on Software Engineering: New Ideas and Emerging Results, IC...

    2021

  27. [35]

    Cheryl Lee, Chunqiu Steven Xia, Jen-tse Huang, Zhouruixin Zhu, Lingming Zhang, and Michael R Lyu. 2024. A Unified Debugging Approach via LLM-Based Multi-Agent Synergy. arXiv preprint arXiv:2404.17153 (2024)

    2024

  28. [36]

    Zhenmin Li, Shan Lu, Suvda Myagmar, and Yuanyuan Zhou. 2006. CP-Miner: Finding Copy-Paste and Related Bugs in Large-Scale Software Code. IEEE Trans. Software Eng. 32, 3 (2006), 176–192. https://doi.org/10.1109/TSE.2006.28

    2006 doi

  29. [37]

    Yiling Lou, Ali Ghanbari, Xia Li, Lingming Zhang, Haotian Zhang, Dan Hao, and Lu Zhang. 2020. Can automated program repair refine fault localization? a unified debugging approach. In ISSTA ’20: 29th ACM SIGSOFT International Symposium on Software Testing and Analysis, Virtual ...

    2020

  30. [38]

    Pedro Machado, José Campos, and Rui Abreu. 2013. MZoltar: Automatic Debugging of Android Applications. In Proceedings of the 2013 International Workshop on Software Development Lifecycle for Mobile . ACM, Saint Petersburg Russia, 9–16. https://doi.org/10.1145/2501553.2501556

    2013

  31. [39]

    George Mathew and Kathryn T. Stolee. 2021. Cross-language code search using static and dynamic analyses. InESEC/FSE ’21: 29th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, Athens, Greece, August 23-28, 2021 , Diomi...

    2021

  32. [40]

    William M McKeeman. 1998. Differential Testing for Software. Digital Technical Journal 10, 1 (1998), 100–107

    1998

  33. [41]

    Sewon Min, Xinxi Lyu, Ari Holtzman, Mikel Artetxe, Mike Lewis, Hannaneh Hajishirzi, and Luke Zettlemoyer. 2022. Rethinking the role of demonstrations: What makes in-context learning work? arXiv preprint arXiv:2202.12837 (2022)

    2022 arXiv

  34. [42]

    Jesús Morán, Antonia Bertolino, Claudio de la Riva, and Javier Tuya. 2024. Automatic Debugging of Design Faults in MapReduce Applications. IEEE Trans. Software Eng. 50, 4 (2024), 956–978. https://doi.org/10.1109/TSE.2024.3369766

    2024

  35. [43]

    Roy, and Kevin A

    Kawser Wazed Nafi, Tonny Shekha Kar, Banani Roy, Chanchal K. Roy, and Kevin A. Schneider. 2019. CLCDSA: Cross Language Code Clone Detection using Syntactical Features and API Documentation. In 34th IEEE/ACM International Conference on Automated Software Engineering, ASE 2019, ...

    2019

  36. [44]

    Hellendoorn, Bogdan Vasilescu, and Brad A

    Daye Nam, Andrew Macvean, Vincent J. Hellendoorn, Bogdan Vasilescu, and Brad A. Myers. 2024. Using an LLM to Help With Code Understanding. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, ICSE 2024, Lisbon, Portugal, April 14-20, 2024 . ACM...

    2024

  37. [45]

    Anh Tuan Nguyen, Tung Thanh Nguyen, and Tien N. Nguyen. 2013. Lexical statistical machine translation for language migration. In Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering, ESEC/FSE’13,...

    2013

  38. [46]

    Changan Niu, Chuanyi Li, Vincent Ng, Dongxiao Chen, Jidong Ge, and Bin Luo. 2023. An Empirical Comparison of Pre-Trained Models of Source Code. In 45th IEEE/ACM International Conference on Software Engineering, ICSE 2023, Melbourne, Australia, May 14-20, 2023 . IEEE, 2136–2148...

    2023

  39. [47]

    Rangeet Pan, Ali Reza Ibrahimzada, Rahul Krishna, Divya Sankar, Lambert Pouguem Wassi, Michele Merler, Boris Sobolev, Raju Pavuluri, Saurabh Sinha, and Reyhaneh Jabbarvand. 2024. Lost in translation: A study of bugs introduced by large language models while translating code. I...

    2024

  40. [48]

    Paige Rodeghero, Collin McMillan, Paul W McBurney, Nigel Bosch, and Sidney D’Mello. 2014. Improving automated source code summarization via an eye-tracking study of programmers. InProceedings of the 36th international conference on Software engineering. 390–401

    2014

  41. [49]

    Ross, Fernando Martinez, Stephanie Houde, Michael J

    Steven I. Ross, Fernando Martinez, Stephanie Houde, Michael J. Muller, and Justin D. Weisz. 2023. The Programmer’s Assistant: Conversational Interaction with a Large Language Model for Software Development. In Proceedings of the 28th International Conference on Intelligent Use...

    2023

  42. [50]

    Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jérémy Rapin, et al . 2023. Code llama: Open foundation models for code. arXiv preprint arXiv:2308.12950 (2023)

    2023 arXiv

  43. [51]

    Baptiste Rozière, Marie-Anne Lachaux, Lowik Chanussot, and Guillaume Lample. 2020. Unsupervised Translation of Programming Languages. In Advances in Neural Information Processing Systems 33: Annual Conference on Neural Information Processing Systems 2020, NeurIPS 2020, Decembe...

    2020

  44. [52]

    Wojciech Samek, Thomas Wiegand, and Klaus-Robert Müller. 2017. Explainable artificial intelligence: Understanding, visualizing and interpreting deep learning models. arXiv preprint arXiv:1708.08296 (2017)

    2017 arXiv

  45. [53]

    Ehud Yehuda Shapiro. 1982. Algorithmic program debugging. Yale University

    1982

  46. [54]

    Bonita Sharif and Jonathan I. Maletic. 2010. The Effects of Layout on Detecting the Role of Design Patterns. InProceedings 23rd IEEE Conference on Software Engineering Education and Training, CSEE&T 2010, Pittsburgh, Pennsylvania, USA, 9-12 March 2010. IEEE Computer Society, 4...

    2010 doi

  47. [55]

    Singh, Kapil Vaidya, Vinayshekhar Bannihatti Kumar, Sopan Khosla, Balakrishnan Narayanaswamy, Rashmi Gangadharaiah, and Tim Kraska

    Vikramank Y. Singh, Kapil Vaidya, Vinayshekhar Bannihatti Kumar, Sopan Khosla, Balakrishnan Narayanaswamy, Rashmi Gangadharaiah, and Tim Kraska. 2024. Panda: Performance Debugging for Databases using LLM Agents. In14th Conference on Innovative Data Systems Research, CIDR 2024,...

    2024

  48. [57]

    Randy Stein and Susan Brennan. 2004. Another person’s eye gaze as a cue in solving programming problems. In Proceedings of the 6th International Conference on Multimodal Interfaces, ICMI 2004, State College, PA, USA, October 13-15, 2004, Rajeev Sharma, Trevor Darrell, Mary P. ...

    2004

  49. [58]

    Marc Szafraniec, Baptiste Rozière, Hugh Leather, Patrick Labatut, François Charton, and Gabriel Synnaeve. 2023. Code Translation with Compiler Representations. In The Eleventh International Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1-5, 2023 . Open...

    2023

  50. [59]

    Yao Wan, Yang He, Zhangqian Bi, Jianguo Zhang, Hongyu Zhang, Yulei Sui, Guandong Xu, Hai Jin, and Philip S. Yu. 2024. Deep Learning for Code Intelligence: Survey, Benchmark and Toolkit. CoRR abs/2401.00288 (2024). https: //doi.org/10.48550/ARXIV.2401.00288 arXiv:2401.00288

    2024 doi arXiv

  51. [60]

    Mark Weiser. 1984. Program slicing. IEEE Transactions on software engineering 4 (1984), 352–357

    1984

  52. [61]

    Weisz, Michael J

    Justin D. Weisz, Michael J. Muller, Steven I. Ross, Fernando Martinez, Stephanie Houde, Mayank Agarwal, Kartik Talamadupula, and John T. Richards. 2022. Better Together? An Evaluation of AI-Supported Code Translation. In IUI 2022: 27th International Conference on Intelligent U...

    2022

  53. [62]

    Xiaoyuan Xie, Zicong Liu, Shuo Song, Zhenyu Chen, Jifeng Xuan, and Baowen Xu. 2016. Revisit of Automatic Debugging via Human Focus-Tracking Analysis. In Proceedings of the 38th International Conference on Software Engineering . ACM, Austin Texas, 808–819. https://doi.org/10.11...

    2016

  54. [63]

    Xuejun Yang, Yang Chen, Eric Eide, and John Regehr. 2011. Finding and understanding bugs in C compilers. In Proceedings of the 32nd ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI 2011, San Jose, CA, USA, June 4-8, 2011 , Mary W. Hall and David A...

    2011

  55. [64]

    Zhen Yang, Fang Liu, Zhongxing Yu, Jacky Wai Keung, Jia Li, Shuo Liu, Yifan Hong, Xiaoxue Ma, Zhi Jin, and Ge Li

  56. [65]

    Cristian Zamfir and George Candea. 2010. Execution Synthesis: A Technique for Automated Software Debugging. In Proceedings of the 5th European Conference on Computer Systems (EuroSys ’10) . Association for Computing Machinery, New York, NY, USA, 321–334. https://doi.org/10.114...

    2010

  57. [66]

    Exploring and Unleashing the Power of Large Language Models in Automated Code Translation. Proc. ACM Softw. Eng. 1, FSE (2024), 1585–1608. https://doi.org/10.1145/3660778

    2024 doi

  58. [68]

    Tianyi Zhang and Miryung Kim. 2017. Automated Transplantation and Differential Testing for Clones. In 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE) . IEEE, Buenos Aires, 665–676. https://doi.org/ 10.1109/ICSE.2017.67 Received 20 February 2007; revi...

    2017 doi

  59. [2024]

    Towards Translating Real-World Code with LLMs: A Study of Translating to Rust.arXiv preprint arXiv:2405.11514 (2024)

    2024 arXiv

Pith tools

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