Pith. sign in

REVIEW 4 major objections 6 minor 60 references

Identifying Root Causes of Null Pointer Exceptions with Logical Inferences

T0 review · 4 major / 6 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 LogicFL locates the root causes of Null Pointer Exceptions by logical inference, outperforming LLM-based fault localization on 76 Java bugs.

desk verdict A genuinely new, cheap, traceable rule-based NPE fault localizer that deserves review, but its headline edge over FuseFL is one un-significant three-bug gap. read the letter →

arxiv 2412.01005 v1 pith:T56OEMAY submitted 2024-12-01 cs.SE

Jindae Kim , Jaewoo Song This is my paper · ORCID
classification cs.SE
keywords FaultlocalizationNullpointerexceptionLogicprogrammingPrologKnowledgerepresentationTraceabledebuggingLLM-basedSoftware
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

This paper argues that fault localization for Null Pointer Exceptions can be automated as a logical deduction process rather than by querying a language model. It proposes LogicFL, which collects logical facts about the faulty code and test execution, then applies 73 Prolog rules that encode common knowledge about how null values are passed around. On 76 NPE bugs from Apache Commons and Defects4J, the technique matched all fault locations for 67 bugs (88.16%), above the two LLM-based baselines, at a fraction of the cost and with every inference step traceable. The point of the work is that for problems with well-organized knowledge, a small, transparent reasoning engine can compete with and even surpass expensive black-box models.

What carries the argument

The load-bearing mechanism is the Prolog knowledge base assembled per bug: semantic facts (method invocations, arguments, returns, references) and code facts (classes, expressions, source ranges) collected by static analysis, plus val/3 facts from instrumented execution recording observed null values. A set of 73 rules encodes the knowledge, with the main query find_npe_cause/4 enumerating (expression, line, cause, location) candidates through the npe/2 and cause_of/3 rules. The three identification schemes Direct, Origin, and Transfer define cause_of/3, and rank_causes/2 applies preferred and filtering conditions, so the output is a ranked list of causes whose derivation can be replayed step by step.

What would settle it

Apply LogicFL to a fresh set of NPE bugs from other Java projects: if the fraction of fully matched bugs drops far below 88.16% because the fixed 73 rules cannot express the null-transfer patterns in the new bugs, the general-accuracy claim would be refuted.

Watch

Extended reading notes

Core claim

LogicFL's central claim is that the root cause of an NPE is what a human deduces when tracking a null value from the throwing expression back to its origin, and that this deduction can be encoded as a Prolog knowledge base. The system first identifies the null expression at the throw site using JEP 358's helpful NPE messages and stack traces, then applies three identification schemes: Direct, which blames the null expression itself; Origin, which traces back to where the null was created; and Transfer, which enumerates the intermediate locations that could have propagated the null. Ranking rules promote candidates that return null, assign the value inside the method, or are the only non-test method on the stack, and filter out test code and pass-through methods. The paper reports that this fully deterministic process matched all fault locations and causes for 67 of 76 bugs, was faster than two LLM-based techniques at ranking, and produced a deduction trail that can be inspected with Prolog's trace.

Load-bearing premise

The results depend on the manually labelled causes and the choice of rules and their order not being shaped by the same 76-bug benchmark used to report the 88.16% accuracy.

Editorial extensions

If this is right

  • Fault localization no longer needs to be treated as an opaque probabilistic task: for a well-understood error type, a fixed set of logical rules can reproduce a developer's reasoning and expose why each candidate was chosen.
  • Developers can run the entire analysis on a typical laptop, with an average of 21.63 seconds per bug and under two minutes in the worst case, including test execution.
  • The per-bug cost of roughly $0.0002 makes it practical to run the technique continuously on every failing test, not just on expensive one-off queries.
  • Because each rule's contribution can be measured (e.g., the Direct scheme found 83.68% of locations, while Origin found 11 locations in 10 bugs), the technique can be improved by editing rules rather than retraining a model.
  • If the paper is right, the same architecture can be ported to other error types or security vulnerabilities by swapping in new fact collectors and rule sets, since Prolog query time is a small fraction of total runtime.

Reading between the lines

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

  • A natural next experiment is to enlarge the rule set to cover implicit type conversions, such as unboxing null to a primitive boolean, which the paper itself identifies as the reason six Defects4J bugs were missed; the expectation would be that most of those misses disappear.
  • The traceable deduction trail could be rendered as natural-language explanations or IDE jumps, which would let LogicFL match the explanation feature of LLM-based techniques while keeping the same candidates.
  • Combining LogicFL's candidate ranking with a cheap spectrum-based suspiciousness score could reduce the Top-1 disadvantage seen against FuseFL, since the paper reports AutoFL had lower average unnecessary examination.
  • The same benchmark and rules would make a strong testbed for a hybrid: use LogicFL's trace to generate few-shot examples for an LLM, potentially fixing the outliers without sacrificing traceability.
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 / 6 minor

Summary. The paper proposes LogicFL, a Prolog-based fault localization technique specialized for Null Pointer Exceptions (NPEs). LogicFL first collects logical facts from static analysis, coverage information, stack traces, and dynamic expression-value monitoring; it then applies a hand-written set of 73 rules that encode NPE-oriented domain knowledge and general program behavior. The rules deduce candidate NPE causes and rank them using preferred/filtering conditions (Sections 3.2-3.3). The authors evaluate LogicFL on a self-built benchmark of 76 NPE bugs from Apache Commons and Defects4J, comparing against two LLM-based techniques, AutoFL and FuseFL, both run with GPT-4o. They report that LogicFL fully matched fault locations for 67/76 bugs (88.16%), versus 56 for AutoFL and 64 for FuseFL, with lower runtime and cost (average 21.63 seconds; $0.0153 total). The paper also reports per-rule effectiveness analysis and argues that LogicFL's deduction process is fully traceable.

Significance. If the reported results hold, LogicFL is a meaningful contribution: it offers a deterministic, explainable, and extremely cheap alternative to LLM-based fault localization for a specific but frequent bug type. The paper ships a replication package, SWISH notebooks, a benchmark of 76 labeled NPE bugs, and a per-rule analysis that is genuinely useful for understanding why the technique works and where it fails. The strengths of traceability, reproducibility, and low cost are real and should be credited. However, the significance is conditional: the main comparative claim rests on a self-built benchmark with manually labeled ground truth, rules and ranking conditions tuned during development, and a primary accuracy comparison that lacks any statistical support. As presented, the evidence supports the claim that LogicFL is a promising and practical technique, but not yet the claim that it significantly outperforms strong LLM-based baselines.

major comments (4)
  1. [Section 5.1, Table 2] The headline result that LogicFL matches 67/76 bugs versus 64/76 for FuseFL is not supported by any significance test. The paper explicitly states that FuseFL's matched bugs varied from 61 to 64 across 10 trials and that the best trial was selected. A 3-bug margin is therefore well within FuseFL's own trial variance. A McNemar test on the per-bug discordant pairs would likely be non-significant (for a union size of about 68 bugs, the two-tailed binomial p-value would be around 0.37). The authors should release the per-bug matched/not-matched outcomes for each technique and report McNemar exact tests for LogicFL versus each baseline on the primary matched-bug metric. Without this, the claim of '4.69% more bugs than FuseFL' is not established.
  2. [Section 3.3 and Section 4.2] There is a clear overfitting risk in the evaluation design. The rule order in Listing 5 and the ranking conditions in Listing 6 were chosen because they were 'effective in our preliminary investigation during rule development' (Section 3.3). The benchmark's ground truth was manually created by the authors and reviewed by auditors (Section 4.2), but the same benchmark is used both to tune the rules and to report the final 88.16% accuracy. The paper should either validate LogicFL on an independently constructed NPE dataset, pre-register the rule set and ordering before benchmark evaluation, or report sensitivity analyses showing that the result is robust to rule-order and ranking-condition choices. This is load-bearing for the external-validity claims in Section 7.
  3. [Section 4.4 and Section 5.1] The baseline comparisons were modified in ways that could favor LogicFL. FuseFL's SBFL component was removed from the prompt; AutoFL's prompt was rephrased for line-level localization; and FuseFL's reported number is the best of 10 trials while LogicFL is deterministic. These modifications are understandable given the original tools' assumptions, but they mean the comparison is not a direct comparison with FuseFL/AutoFL as originally proposed. The paper should justify each modification more strongly, report all 10 trials for FuseFL (e.g., mean, median, and variance), and present the FuseFL result without best-of-10 selection unless the selection criterion is justified as the intended use of the technique. Additionally, the cost comparison in Table 3 uses only the best FuseFL trial, which understates the actual cost of the technique when repeated trials are used.
  4. [Section 5.4 and Figure 4b] The claim that 'all of the defined rules contributed to identify at least one fault location' is supported by the pie-chart counts, but the ranking-rule analysis in Figure 4b shows that two of the three preferred-condition rules occasionally have negative influence on ranking. The paper correctly acknowledges this, but the conclusion that LogicFL's ranking is efficient is weakened by the fact that the only significance test reported in the paper (Kruskal-Wallis on AUE, p=0.364) shows no significant difference among techniques. The authors should temper the RQ2 discussion and avoid implying that LogicFL's ranking is better than the baselines, since the data do not support that.
minor comments (6)
  1. [Section 4.5] Typo: 'similart' should be 'similar'.
  2. [Section 5.3] Typo: 'ouput' should be 'output'.
  3. [Reference [31]] The replication-package reference lists 'N/A' as the author and uses an anonymous Figshare link; this is acceptable for anonymous review but must be completed before publication.
  4. [Section 3.2] The running example in Listing 2 is hard to follow because the names expr1, expr2, m_stream_1, m_stream_2, and m_stream_3 are not mapped to concrete source-level identifiers. A short table or annotation connecting these atoms to the original code would improve readability.
  5. [Section 5.4] The definitions of 'positive' and 'negative' influence for the ranking rules are clear from the text, but Figure 4b would benefit from a caption explicitly defining what 'influence' means and how 'negative' versus 'none' is distinguished.
  6. [Section 7] The internal-validity paragraph acknowledges that data leakage may favor AutoFL and FuseFL because LLM training data may contain the evaluation bugs. This is a fair point, but it should also be noted that the same leakage concern applies to the benchmark construction and rule-development process, since the authors' knowledge of the bugs is necessarily embedded in the rule design.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: LogicFL's reported matches are empirical outcomes of stated rules applied to independently collected facts, not restatements of its inputs.

full rationale

LogicFL's derivation chain is transparent: it collects facts from source and test execution (CoverageAnalyzer, StaticAnalyzer, DynamicAnalyzer, Section 3.2), combines them with explicitly stated inference rules (Listings 4-6, Section 3.3), and queries find_npe_cause/4. The outputs are logical consequences of these inputs, not restatements of benchmark labels. The benchmark ground truth (Section 4.2) was constructed by manual inspection of developer patches and independently audited, and the rules themselves are stated domain heuristics rather than learned encodings of those labels. The central accuracy claim of 67/76 matched bugs (Section 5.1, Table 2) is an empirical measurement against this ground truth and against two external, independently published LLM baselines (AutoFL and FuseFL). The acknowledged tuning of rule order in preliminary investigation (Section 3.3: 'We chose this order since it was effective in our preliminary investigation during rule development') and the self-built nature of part of the benchmark are evaluation-independence and overfitting threats, explicitly discussed in Section 7, but they do not make the derivation circular: the matched-bug outcomes are not forced by construction, as shown by the six bugs LogicFL fails to match (Section 6.1). No load-bearing self-citation appears; references [18,19,31] merely point to replication artifacts. The absence of a significance test on the 3-bug margin over FuseFL (Section 5.1) is a statistical-reporting concern, not a circularity of the derivation.

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

LogicFL introduces no new conceptual entities such as particles, forces, or latent variables. The logical atoms (expr1, p_stream_1) are reifications of existing code entities, not new ontology. The hand-defined rule set and its ordering act as free design parameters, and the listed domain assumptions are load-bearing for the empirical claim.

free parameters (2)
  • Rule order for cause_of/3 and ranking conditions = Order: Direct/Origin for Null Arg and Null Ref before Transfer; prefer_cond and filter_cond as listed
    Chosen based on preliminary investigation during rule development (Section 3.3), not derived from theory; the benchmark on which it is evaluated informed these choices.
  • Rule set size and predicate set = 73 Prolog rules (25 for NPE causes, 48 for common behavior)
    Hand-defined by the authors; completeness is not proven, as shown by six unmatched bugs needing rules not yet defined (Section 6.1).
assumptions (5)
  • domain assumption An NPE's cause can be identified by tracing null transfers backward from the null expression via assignments, returns, and arguments.
    Central to cause_of/3 and copied_from/2 in Section 3.3; the six unmatched bugs in Section 6.1 show this does not cover all NPE mechanisms (e.g., unboxing null).
  • domain assumption The null expression at which an NPE is thrown is available from JEP 358 helpful NPE messages and stack traces.
    LogicFL relies on npe(Expr, Line) derived from stack traces and JEP 358 (Section 3.3); on JDKs without helpful NPE messages, this fact source may be weaker.
  • domain assumption Facts collected from covered code lines and observed null values during failed test execution are sufficient to identify the true cause.
    DynamicAnalyzer only records null-valued expressions and only for lines with breakpoints (Section 3.2); if the origin of null is not dynamically observed, the Origin scheme may miss it.
  • domain assumption Manual labels for fault locations and causes in the NPE benchmark are correct and representative.
    Used as ground truth for evaluation (Sections 4.2 and 4.3); labeling was by one author plus three auditors, and exclusion of bugs without failing tests shapes the benchmark.
  • ad hoc to paper Rule order in Prolog reflects preference: earlier rules yield higher-ranked candidates.
    The rank_causes/2 order was set by the authors rather than derived; the paper notes the order can be adjusted based on further analysis (Section 3.3).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Identifying Root Causes of Null Pointer Exceptions with Logical Inferences." pith.science (2026). https://pith.science/paper/T56OEMAY

@misc{pith2026241201005,
  author       = {Pith},
  title        = {Pith review of: Identifying Root Causes of Null Pointer Exceptions with Logical Inferences},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/T56OEMAY}},
  note         = {Machine review of arXiv:2412.01005}
}
read the original abstract

Recently, Large Language Model (LLM)-based Fault Localization (FL) techniques have been proposed, and showed improved performance with explanations on FL results. However, a major issue with LLM-based FL techniques is their heavy reliance on LLMs, which are often unreliable, expensive, and difficult to analyze or improve. When results are unsatisfactory, it is challenging both to determine a cause and to refine a technique for better outcomes. To address this issue, we propose LogicFL, a novel logical fault localization technique for Null Pointer Exceptions (NPEs). With logic programming, LogicFL imitates human developers' deduction process of fault localization, and identifies causes of NPEs after logical inferences on collected facts about faulty code and test execution. In an empirical evaluation of 76 NPE bugs from Apache Commons projects and the Defects4J benchmark, LogicFL accurately identified the fault locations and pinpointed the exact code fragments causing the NPEs for 67 bugs (88.16%), which were 19.64% and 4.69% more bugs than two compared LLM-based FL techniques respectively. In addition, LogicFL can be executed on a low-performance machine similar to a typical laptop, with an average runtime of 21.63 seconds and a worst-case time of under two minutes, including test execution and output file generation. Moreover, when compared to the two LLM-based FL techniques using the GPT-4o model, LogicFL was significantly more cost-efficient, as those techniques required 343.94 and 3,736.19 times the cost of LogicFL, respectively. Last but not least, the deduction process in LogicFL for providing FL results is fully traceable, enabling us to understand the reasoning behind the technique's outcomes and to further enhance the technique.

Figures

Figures reproduced from arXiv: 2412.01005 by the authors.

Figure 1
Figure 1. Logical Fault Localization Process for Null Pointer Exceptions [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Fault Localization Results of Top-10 Candidates. [PITH_FULL_IMAGE:figures/full_fig_p013_2.png] view at source ↗
Figure 3
Figure 3. Execution Time of LogicFL Components Measured on Amazon EC2 t3.small [PITH_FULL_IMAGE:figures/full_fig_p014_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Rule Usages and Influence of LogicFL on the NPE Benchmark. identifying the origin as a cause was not successful for LLM-based techniques. However, analyzing why LLM-based techniques provide such undesirable outcome would be difficult, if we only had information obtaine…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

60 extracted references · 30 canonical work pages

  1. [1]

    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

    work page 2007

  2. [2]

    van Gemund

    Rui Abreu, Peter Zoeteweij, and Arjan J.C. van Gemund. 2009. Spectrum-Based Multiple Fault Localization. In 2009 IEEE/ACM International Conference on Automated Software Engineering . 88–99. https://doi.org/10.1109/ASE.2009.25

    work page doi:10.1109/ase.2009.25 2009

  3. [3]

    Amazon Web Services, Inc. 2024. Amazon EC2 On-Demand Instance Pricing. https://aws.amazon.com/ec2/pricing/on- demand. Accessed: 2024-09-04

    work page 2024

  4. [4]

    Amazon Web Services, Inc. 2024. CPU Options for Amazon EC2 Instances. https://docs.aws.amazon.com/AWSEC2/ latest/UserGuide/instance-optimize-cpu.html. Accessed: 2024-09-04

    work page 2024

  5. [5]

    Soremekun, Sudipta Chattopadhyay, Emamurho Ugherughe, and Andreas Zeller

    Marcel Böhme, Ezekiel O. Soremekun, Sudipta Chattopadhyay, Emamurho Ugherughe, and Andreas Zeller. 2017. Where is the bug and how is it fixed? an experiment with practitioners. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (Paderborn, Germany) (ESEC/FSE 2017). Association for Computing Machinery, New York, NY, USA, 1...

    arXiv 2017

  6. [6]

    Ronald Brachman and Hector Levesque. 2004. Knowledge representation and reasoning . Morgan Kaufmann

    work page 2004

  7. [7]

    Android Developers. 2024. Crashes - Android Vitals. https://developer.android.com/topic/performance/vitals/crash Accessed: 2024-09-05

    work page 2024

  8. [8]

    Jing Duan, Shujuan Jiang, Qiao Yu, Kai Lu, Xu Zhang, and Yiwen Yao. 2019. An Automatic Localization Tool for Null Pointer Exceptions. IEEE Access 7 (2019), 153453–153465. https://doi.org/10.1109/ACCESS.2019.2948366

    arXiv 2019

Show all 60 references
  1. [9]

    Thomas Durieux, Benoit Cornu, Lionel Seinturier, and Martin Monperrus. 2017. Dynamic patch generation for null pointer exceptions using metaprogramming. In 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER). 349–358. https://doi.o...

    2017

  2. [10]

    Davide Ginelli, Oliviero Riganelli, Daniela Micucci, and Leonardo Mariani. 2021. Exception-Driven Fault Localization for Automated Program Repair. In 2021 IEEE 21st International Conference on Software Quality, Reliability and Security (QRS). 598–607. https://doi.org/10.1109/Q...

    2021

  3. [11]

    Human-Centered Artificial Intelligence. 2024. The Stanford AI Index Report 2024. https://aiindex.stanford.edu/report/ Accessed: 2024-09-04

    2024

  4. [12]

    Jiajun Jiang, Yingfei Xiong, Hongyu Zhang, Qing Gao, and Xiangqun Chen. 2018. Shaping program repair space with existing patches and similar code. In Proceedings of the 27th ACM SIGSOFT International Symposium on Software Testing and Analysis (Amsterdam, Netherlands) (ISSTA 20...

    2018

  5. [13]

    Shujuan Jiang, Wei Li, Haiyang Li, Yanmei Zhang, Hongchang Zhang, and Yingqi Liu. 2012. Fault Localization for Null Pointer Exception Based on Stack Trace and Program Slicing. In 2012 12th International Conference on Quality Software . 9–12. https://doi.org/10.1109/QSIC.2012.36

    2012 doi

  6. [14]

    Jones and Mary Jean Harrold

    James A. Jones and Mary Jean Harrold. 2005. Empirical evaluation of the tarantula automatic fault-localization technique. In Proceedings of the 20th IEEE/ACM International Conference on Automated Software Engineering (Long Beach, CA, USA) (ASE ’05). Association for Computing M...

    2005 arXiv

  7. [15]

    René Just, Darioush Jalali, and Michael D. Ernst. 2024. Defects4J: A Database of Real Bugs to Enable Controlled Testing Studies for Java Programs. https://github.com/rjust/defects4j. Accessed: 2024-09-04

    2024

  8. [16]

    Sungmin Kang, Gabin An, and Shin Yoo. 2024. A Quantitative and Qualitative Evaluation of LLM-Based Explainable Fault Localization. Proc. ACM Softw. Eng. 1, FSE, Article 64 (jul 2024), 23 pages. https://doi.org/10.1145/3660771

    2024 doi

  9. [17]

    Dongsun Kim, Jaechang Nam, Jaewoo Song, and Sunghun Kim. 2013. Automatic patch generation learned from human-written patches. In 2013 35th International Conference on Software Engineering (ICSE) . 802–811. https://doi.org/ 10.1109/ICSE.2013.6606626

    2013

  10. [18]

    Jindae Kim. 2024. SWISH for the NPE Benchmark. http://selogic.seoultech.ac.kr:3050/p/testing_npe_rules.swinb. Accessed: 2024-12-01. , Vol. 1, No. 1, Article . Publication date: December 2024. 20 Kim and Song

    2024

  11. [19]

    Jindae Kim. 2024. SWISH Notebooks for the NPE Bugs. http://selogic.seoultech.ac.kr:3050/p/logicfl_sbj_notebooks. swinb. Accessed: 2024-12-01

    2024

  12. [20]

    Jeongho Kim, Jindae Kim, and Eunseok Lee. 2019. VFL: Variable-based fault localization. Information and software technology 107 (2019), 179–191

    2019

  13. [21]

    Jindae Kim and Sunghun Kim. 2019. Automatic patch generation with context-based change application. Empirical Software Engineering 24 (2019), 4071–4106

    2019

  14. [22]

    Pavneet Singh Kochhar, Xin Xia, David Lo, and Shanping Li. 2016. Practitioners’ expectations on automated fault localization. In Proceedings of the 25th International Symposium on Software Testing and Analysis(Saarbrücken, Germany) (ISSTA 2016). Association for Computing Machi...

    2016 doi

  15. [23]

    Takeshi Kojima, Shixiang (Shane) Gu, Machel Reid, Yutaka Matsuo, and Yusuke Iwasawa. 2022. Large Language Models are Zero-Shot Reasoners. In Advances in Neural Information Processing Systems , S. Koyejo, S. Mohamed, A. Agarwal, D. Belgrave, K. Cho, and A. Oh (Eds.), Vol. 35. C...

    2022

  16. [24]

    Yiğit Küçük, Tim A. D. Henderson, and Andy Podgurski. 2021. Improving Fault Localization by Integrating Value and Predicate Based Causal Inference Techniques. In Proceedings of the 43rd International Conference on Software Engineering (Madrid, Spain) (ICSE ’21). IEEE Press, 64...

    2021

  17. [25]

    Xia Li, Wei Li, Yuqun Zhang, and Lingming Zhang. 2019. DeepFL: integrating multiple fault diagnosis dimensions for deep fault localization. In Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis (Beijing, China) (ISSTA 2019). Associatio...

    2019

  18. [26]

    Yi Li, Shaohua Wang, and Tien Nguyen. 2021. Fault Localization with Code Coverage Representation Learning. In2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE) . 661–673. https://doi.org/10.1109/ICSE43902. 2021.00067

    2021

  19. [27]

    Zhenmin Li, Lin Tan, Xuanhui Wang, Shan Lu, Yuanyuan Zhou, and Chengxiang Zhai. 2006. Have things changed now? an empirical study of bug characteristics in modern open source software. In Proceedings of the 1st Workshop on Architectural and System Support for Improving Softwar...

    2006

  20. [28]

    Goetz Lindenmaier and Ralf Schmelter. 2019. JEP 358: Helpful NullPointerExceptions. https://openjdk.org/jeps/358. Accessed: 2024-09-05

    2019

  21. [29]

    Yiling Lou, Qihao Zhu, Jinhao Dong, Xia Li, Zeyu Sun, Dan Hao, Lu Zhang, and Lingming Zhang. 2021. Boosting coverage-based fault localization via graph-based representation learning. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and S...

    2021

  22. [30]

    Alexandru Marginean, Johannes Bader, Satish Chandra, Mark Harman, Yue Jia, Ke Mao, Alexander Mols, and Andrew Scott. 2019. SapFix: Automated End-to-End Repair at Scale. In 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (IC...

    2019

  23. [31]

    N/A. 2024. LogicFL Replication Package. https://figshare.com/s/8b60e4174e0c4f3b4341. Accessed: 2024-09-12

    2024

  24. [32]

    Lee Naish, Hua Jie Lee, and Kotagiri Ramamohanarao. 2011. A model for spectra-based software diagnosis. ACM Trans. Softw. Eng. Methodol. 20, 3, Article 11 (aug 2011), 32 pages. https://doi.org/10.1145/2000791.2000795

    2011

  25. [33]

    Neelofar Neelofar, Lee Naish, Jason Lee, and Kotagiri Ramamohanarao. 2017. Improving spectral-based fault localization using static analysis. Software: Practice and Experience 47, 11 (2017), 1633–1655. https://doi.org/10.1002/spe.2490 arXiv:https://onlinelibrary.wiley.com/doi/...

    2017 doi

  26. [34]

    OpenAI. 2024. OpenAI Platform - Models Documentation. https://platform.openai.com/docs/models Accessed: 2024-09-02

    2024

  27. [35]

    OpenAI, Inc. 2024. OpenAI API Pricing. https://openai.com/api/pricing/. Accessed: 2024-09-04

    2024

  28. [36]

    Chris Parnin and Alessandro Orso. 2011. Are automated debugging techniques actually helping programmers?. In Proceedings of the 2011 International Symposium on Software Testing and Analysis (Toronto, Ontario, Canada) (ISSTA ’11). Association for Computing Machinery, New York, ...

    2011

  29. [37]

    Ernst, Deric Pang, and Benjamin Keller

    Spencer Pearson, José Campos, René Just, Gordon Fraser, Rui Abreu, Michael D. Ernst, Deric Pang, and Benjamin Keller. 2017. Evaluating and Improving Fault Localization. In 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE). 609–620. https://doi.org/10.1...

    2017 doi

  30. [38]

    Saurabh Sinha, Hina Shah, Carsten Görg, Shujuan Jiang, Mijung Kim, and Mary Jean Harrold. 2009. Fault localization and repair for Java runtime exceptions. In Proceedings of the Eighteenth International Symposium on Software Testing and Analysis (Chicago, IL, USA) (ISSTA ’09). ...

    2009

  31. [39]

    Jeongju Sohn and Shin Yoo. 2017. FLUCCS: using code and change metrics to improve fault localization. In Proceedings of the 26th ACM SIGSOFT International Symposium on Software Testing and Analysis (Santa Barbara, CA, USA) (ISSTA 2017). Association for Computing Machinery, New...

    2017

  32. [40]

    Gregory Tassey. 2002. The economic impacts of inadequate infrastructure for software testing. National Institute of Standards and Technology. RTI Project 7007, 11 (2002), 1–309

    2002

  33. [41]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, brian ichter, Fei Xia, Ed Chi, Quoc V Le, and Denny Zhou

  34. [42]

    Ratnadira Widyasari, Jia Wei Ang, Truong Giang Nguyen, Neil Sharma, and David Lo. 2024. Demystifying Faulty Code: Step-by-Step Reasoning for Explainable Fault Localization. In 2024 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER) . 568–57...

    2024

  35. [43]

    Haryono, Yuan Tian, Hafil Noer Zachiary, and David Lo

    Ratnadira Widyasari, Gede Artha Azriadi Prana, Stefanus A. Haryono, Yuan Tian, Hafil Noer Zachiary, and David Lo

  36. [44]

    Ratnadira Widyasari, Gede Artha Azriadi Prana, Stefanus Agus Haryono, Shaowei Wang, and David Lo. 2022. Real world projects, real faults: evaluating spectrum based fault localization techniques on Python projects. Empirical Software Engineering 27, 6 (2022), 147

    2022

  37. [45]

    In2022 IEEE/ACM 30th International Conference on Program Comprehension (ICPC)

    XAI4FL: Enhancing Spectrum-Based Fault Localization with Explainable Artificial Intelligence. In2022 IEEE/ACM 30th International Conference on Program Comprehension (ICPC) . 499–510. https://doi.org/10.1145/3524610.3527902

  38. [46]

    Eric Wong, Vidroha Debroy, Ruizhi Gao, and Yihao Li

    W. Eric Wong, Vidroha Debroy, Ruizhi Gao, and Yihao Li. 2014. The DStar Method for Effective Software Fault Localization. IEEE Transactions on Reliability 63, 1 (2014), 290–308. https://doi.org/10.1109/TR.2013.2285319

    2014

  39. [47]

    Jan Wielemaker, Tom Schrijvers, Markus Triska, and Torbjörn Lager. 2012. Swi-prolog. Theory and Practice of Logic Programming 12, 1-2 (2012), 67–96

    2012

  40. [48]

    Rongxin Wu, Hongyu Zhang, Shing-Chi Cheung, and Sunghun Kim. 2014. CrashLocator: locating crashing faults based on crash stacks. In Proceedings of the 2014 International Symposium on Software Testing and Analysis (San Jose, CA, USA) (ISSTA 2014). Association for Computing Mach...

    2014

  41. [49]

    Eric Wong, Ruizhi Gao, Yihao Li, Rui Abreu, and Franz Wotawa

    W. Eric Wong, Ruizhi Gao, Yihao Li, Rui Abreu, and Franz Wotawa. 2016. A Survey on Software Fault Localization. IEEE Transactions on Software Engineering 42, 8 (2016), 707–740. https://doi.org/10.1109/TSE.2016.2521368

    2016

  42. [50]

    Chunqiu Steven Xia, Yuxiang Wei, and Lingming Zhang. 2023. Automated Program Repair in the Era of Large Pre- trained Language Models. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . 1482–1494. https://doi.org/10.1109/ICSE48619.2023.00129

    2023

  43. [51]

    Zhang, Mike Papadakis, Mark Harman, and Yong Liu

    Yonghao Wu, Zheng Li, Jie M. Zhang, Mike Papadakis, Mark Harman, and Yong Liu. 2023. Large Language Models in Fault Localisation. arXiv:2308.15276 [cs.SE] https://arxiv.org/abs/2308.15276

    2023 arXiv

  44. [52]

    Automated Debugging Considered Harmful

    Xin Xia, Lingfeng Bao, David Lo, and Shanping Li. 2016. “Automated Debugging Considered Harmful” Considered Harmful: A User Study Revisiting the Usefulness of Spectra-Based Fault Localization Techniques with Professionals Using Real Bugs from Large Systems. In 2016 IEEE Intern...

    2016 doi

  45. [53]

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

    2022

  46. [54]

    Qi Xin and Steven P. Reiss. 2017. Leveraging syntax-related code for automated program repair. In2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE) . 660–670. https://doi.org/10.1109/ASE.2017.8115676

    2017

  47. [55]

    Qi Xin and Steven Reiss. 2019. Better Code Search and Reuse for Better Program Repair. In2019 IEEE/ACM International Workshop on Genetic Improvement (GI). 10–17. https://doi.org/10.1109/GI.2019.00012

    2019

  48. [56]

    Aidan Z. H. Yang, Claire Le Goues, Ruben Martins, and Vincent Hellendoorn. 2024. Large Language Models for Test-Free Fault Localization. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (Lisbon, Portugal) (ICSE ’24). Association for Computin...

    2024

  49. [57]

    Jifeng Xuan, Matias Martinez, Favio DeMarco, Maxime Clement, Sebastian Lamelas Marcote, Thomas Durieux, Daniel Le Berre, and Martin Monperrus. 2017. Nopol: Automatic Repair of Conditional Statement Bugs in Java Programs. IEEE Trans. Softw. Eng. 43, 1 (jan 2017), 34–55. https:/...

    2017

  50. [58]

    Ernst, and Lu Zhang

    Daming Zou, Jingjing Liang, Yingfei Xiong, Michael D. Ernst, and Lu Zhang. 2021. An Empirical Study of Fault Localization Families and Their Combinations. IEEE Transactions on Software Engineering 47, 2 (2021), 332–347. https://doi.org/10.1109/TSE.2019.2892102 , Vol. 1, No. 1,...

    2021

  51. [59]

    Muhan Zeng, Yiqian Wu, Zhentao Ye, Yingfei Xiong, Xin Zhang, and Lu Zhang. 2022. Fault localization via efficient probabilistic modeling of program semantics. InProceedings of the 44th International Conference on Software Engineering (Pittsburgh, Pennsylvania) (ICSE ’22). Asso...

    2022

  52. [2022]

    In Advances in Neural Information Processing Systems, S

    Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. In Advances in Neural Information Processing Systems, S. Koyejo, S. Mohamed, A. Agarwal, D. Belgrave, K. Cho, and A. Oh (Eds.), Vol. 35. Curran Associates, Inc., 24824–24837. https://proceedings.neurips.cc/...

    2022

Pith tools

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