Pith. sign in

REVIEW 4 major objections 7 minor 31 references

ConFL: Explainable Concurrent Fault Localization via Hierarchy-Guided LLM Reasoning

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

Pith's one-line read Concurrent fault localization from bug reports alone improves drastically when an LLM reasons over a structured, hierarchically navigated concurrency knowledge base, reaching MRR 0.503 and MAP 0.486 on real-world Java bugs.

desk verdict A genuinely new framework for bug-report-only concurrent fault localization with large claimed gains, but the evidence needs repeated runs and a reported cumulative retrieval success rate before I'd trust the numbers. read the letter →

arxiv 2608.02974 v1 pith:GAG4YUGF submitted 2026-08-04 cs.SE

classification cs.SE
keywords concurrentfaultlocalizationbugreportonlylargelanguagemodelshierarchicalretrievalinteraction-levelDSLconcurrencyknowledgebaseraceconditionsJava
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 claims that localizing concurrency bugs from bug reports alone—no test cases, no execution traces—can be made substantially more accurate and more explainable by giving the LLM structured concurrency knowledge instead of raw code. ConFL builds a Concurrent Knowledge Base from static analysis, then lets an LLM navigate it in fixed stages: pick a component, pick a package, pick a pair of thread entry points, then reason over an interaction-level DSL that lists shared resources, access actions, and locks. On 322 real-world bugs from eight Java projects the paper reports an MRR of 0.503 and a MAP of 0.486, roughly 60% above the strongest baseline. The same pipeline degrades gracefully under misleading bug reports, generalizes to post-cutoff bugs, and stays within a narrow MRR band across four LLM backbones. If this holds, the lesson is that the bottleneck for bug-report-only localization is not raw LLM reasoning but what structured domain knowledge is exposed to it.

What carries the argument

The load-bearing mechanism is the interaction-level DSL embedded in the Concurrent Knowledge Base (CKB). Each interaction is a compact record pairing two thread entry points with a set of shared accesses, where each access point names a method, a variable, an operation (read/write/read-write), a location, and an optional guarding lock. The CKB organizes the same knowledge at four granularities—components, packages, thread entry points, and interactions—and the LLM is only allowed to query it through a small set of retrieval functions. The DSL does the argument's work: it compresses cross-thread behavior into a form short enough for an LLM context window and forces the model to reason about shared-resource interleavings rather than traverse deep Java call chains.

What would settle it

Corrupt the component-level summaries the LLM sees (e.g., shuffle descriptions across components) and re-measure Top-1 on the DatasetGit benchmark; the paper's own failed-case analysis predicts a sharp drop, so little movement would falsify the hierarchy's role. A complementary check is to measure component-selection accuracy on identifier-free reports, where the paper's best-case claim is that hierarchy keeps reasoning on track.

Watch

Extended reading notes

Core claim

The central claim is that hierarchy-guided LLM reasoning over a statically built concurrency knowledge base outperforms both lexical retrieval and direct LLM prompting for concurrent fault localization. ConFL encodes each potential cross-thread interaction as a DSL record pairing two thread entry points with the shared-variable accesses reachable from each, then has the LLM rank methods by reasoning over these records. The method achieves 132 Top-1 hits, MRR 0.503 and MAP 0.486 on DatasetGit, improves file-level MRR from 0.32 (BLCoiR) to 0.76, and reduces hallucinated explanations from 25% to 12% when the DSL is supplied. The paper's framing is that effective fault localization depends more on structured concurrency modeling and guided retrieval than on raw LLM capacity.

Load-bearing premise

The early hierarchy decisions—which component and package match the bug report—must be right, because a wrong choice seals off the correct code before interaction reasoning starts, and those summaries are built from build files, directory structure, and documentation that may be sparse or misleading.

Editorial extensions

If this is right

  • Bug-report-only localization of concurrent faults can reach MRR around 0.5, more than double the strongest prior bug-report-only LLM baseline.
  • Noisy or intentionally misleading reports degrade ConFL far less than they degrade direct LLM prompting, so the gains concentrate exactly where lexical methods fail.
  • The interaction DSL's contribution is separable: removing it lowers Top-1 from 132 to 117 and raises hallucinated explanations from 12% to 25%.
  • Structured concurrency knowledge transfers across LLM backbones and to post-cutoff bugs, indicating the result is not memorization of training-era code.
  • Filtering to concurrency-relevant code alone helps IR baselines modestly (MRR 0.103 to 0.167), but full hierarchy-guided reasoning adds most of the gain.

Reading between the lines

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

  • This suggests a cheap next step the paper leaves implicit: add backtracking or re-ranking across hierarchy levels, since the authors identify early component/package errors as the point where the pipeline becomes unrecoverable.
  • Because the DSL captures shared-variable accesses rather than ordering, the method should transfer best to races and atomicity violations; extending it to happens-before or deadlock faults would require adding temporal or lock-order information to the DSL.
  • The retrieval protocol itself is not concurrency-specific, so the same component-to-package-to-entry-point-to-interaction ladder could be tested on other bug families by swapping the CKB for another structured domain model.
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

4 major / 7 minor

Summary. The paper proposes ConFL, a fault localization framework for concurrent Java bugs that uses only bug reports as input. It statically constructs a Concurrent Knowledge Base (CKB) with component, package, thread-entry, method, and interaction-level DSL elements, then uses an LLM to perform hierarchical retrieval from components down to interacting thread-entry pairs, followed by interaction-DSL-based method ranking and explanation. The evaluation uses 322 bug reports from eight projects (DatasetGit) plus a 32-bug post-cutoff dataset (DatasetPost), comparing against IR baselines (BRTracer, BoostNSift, BLCoiR) and the LLM baseline FlexFL. The paper reports MRR 0.503 and MAP 0.486 on DatasetGit, claims robustness across report-quality strata, ablations showing the importance of hierarchy, CKB, and DSL, additional experiments on unseen bugs and multiple LLM backbones, and a manual evaluation of explanation faithfulness.

Significance. If the empirical claims hold, ConFL is a meaningful step forward for bug-report-only fault localization in the concurrency domain. The interaction DSL is a compact and plausible representation of cross-thread shared-resource behavior, and the hierarchy-guided retrieval design directly targets the search-space and hallucination problems that plague direct LLM prompting. The post-cutoff generalization experiment and the multi-backbone evaluation are welcome attempts to address memorization and model-dependence concerns, and the manual explanation-faithfulness study with reported inter-annotator agreement is a strength. The paper also honestly discusses failure modes, including early hierarchy errors and third-party-library blind spots. However, several load-bearing empirical gaps, described in the major comments, must be addressed before the scale of the claimed improvements can be accepted.

major comments (4)
  1. [5.2.3 (Figure 4)] Figure 4 reports component, package, thread-entry, and method accuracies of 91.92%, 89.80%, 91.30%, and 88.89%, but the text states these are 'measured conditionally at each subsequent stage.' If these values are P(current stage correct | all previous stages correct), the cumulative probability that a report survives all four stages is approximately 0.9192 x 0.8980 x 0.9130 x 0.8889, or about 0.67. Since Section 6.1 admits that 'once an early decision is wrong, subsequent retrieval is constrained to an incorrect scope,' this conditional presentation substantially overstates the reliability of the full hierarchical pathway. The paper should report the unconditional (or joint) success rate of the component-to-entry pathway and quantify how early retrieval errors affect the final MRR/MAP; without this, the claim that hierarchy-guided retrieval is 'highly reliable' is not supported by the presented numbers.
  2. [5.1.3, 5.2.1, 7 (Tables 6, 9, 10, 12)] All headline comparisons are reported as single-run point estimates with no confidence intervals, no repeated runs, and no statistical significance tests, despite the use of LLMs that are not fully deterministic even with temperature=0. The paper uses 'significantly outperforms' repeatedly (e.g., Abstract, Section 5.2.1) without any significance testing or variance reporting. Given that the central claim is a large empirical improvement over baselines, the authors should provide repeated runs or bootstrap confidence intervals for MRR/MAP/Top-k and, where feasible, paired significance tests. This is particularly important because Section 7 acknowledges nondeterminism as an internal-validity threat but does not quantify its effect on the reported results.
  3. [5.2.4, Table 5, Table 12] There is a factual inconsistency in the post-cutoff generalization experiment. Table 5 lists 32 bug reports in DatasetPost (1+4+13+3+4+2+1+4=32), but Section 5.2.4 states 'ConFL achieves 20 Top-1 hits out of 31' and Table 12 appears to be based on either 31 or 32 reports without a clear header count. Because this experiment is load-bearing for the claim that ConFL generalizes to unseen bugs, the authors must correct the dataset count and recompute all DatasetPost metrics consistently. The current inconsistency makes the post-cutoff results difficult to verify.
  4. [5.1.2, 6.4, Abstract] The abstract claims that ConFL 'significantly outperforms state-of-the-art IR-based and LLM-based baselines,' but the main LLM comparison includes only FlexFL. AutoFL and AgentFL are excluded because they require test-case execution, which is a reasonable scoping decision, yet the wording implies a broader comparison with the current state of the art in LLM-based fault localization. The authors should either temper the claim to 'the bug-report-only LLM baseline FlexFL' or add additional bug-report-only LLM baselines that can run under the same constraint. As written, the claim is broader than the evidence supports.
minor comments (7)
  1. [5.1.3] The metric definitions state k in {1, 5, 10}, but Tables 6, 10, and 12 also report Top-3; the definition should be extended or the metric names clarified.
  2. [4.4, 4.5, Figure 2] The manuscript contains a dangling 'Figure ??' reference and two different DSL grammar variants in close proximity (one with SharedAccesses/AccessPoint and one with SharedMethods/MethodAccess/VarAccess); the presentation should be consolidated and the figure reference resolved.
  3. [Table 4, Table 5] The column headers 'Avg.#M' and 'Avg.#F' are undefined; please spell out that M denotes methods and F denotes files, and clarify whether these are averages over bug reports or over project versions.
  4. [Table 6, Tables 9-12] The baseline name is spelled inconsistently as 'Flexfl' in some tables and 'FlexFL' in the text; please unify the capitalization.
  5. [5.2.1 (Table 7)] The file-level comparison with BLCoiR is reported without any information about how the file-level ground truth was derived or whether the same bug reports are used; please specify the file-level evaluation protocol.
  6. [5.2.4 (Figure 5)] The multi-backbone comparison reports only aggregate MRR/MAP without per-project or per-report breakdowns; adding per-backbone Top-k and confidence intervals would make the robustness claim easier to assess.
  7. [7] The internal-validity discussion attributes nondeterminism mitigation to 'deterministic decoding settings,' but deterministic decoding does not guarantee reproducible results across API versions or hardware; please acknowledge this residual nondeterminism explicitly.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: ConFL's main claim is an empirical comparison against external baselines, with a statically constructed knowledge base and held-out evaluation, not a derivation that reduces to its own inputs.

full rationale

The paper's central claim is empirical: hierarchy-guided LLM retrieval over a statically constructed concurrency knowledge base (CKB) improves bug-report-only concurrent fault localization. No numerical parameter is fitted to the evaluation data, and no quantity reported as a 'prediction' is defined in terms of the ground truth or the metric it is compared against. The CKB is built offline from source code via lightweight static analysis (Algorithm 1 and Section 4.2), and evaluation uses held-out bug reports from prior datasets with ground truth taken from fixing commits. The self-citations present in the paper (references [24], [25], [26]) are used for dataset provenance and for one baseline (BLCoiR), not to justify the main result; the comparison against external baselines such as BRTracer, BoostNSift, and FlexFL provides independent evidence. The ablations in Table 10 and the hierarchy-accuracy analysis in Figure 4 are internal measurements, not circular derivations: they quantify component contributions but do not define the headline MRR/MAP. The paper's own failure-mode discussion in Section 6.1 (e.g., 'Once an early decision is wrong, subsequent retrieval is constrained to an incorrect scope') is a limitation statement and a measurement-quality concern, not evidence that the result is forced by construction. Therefore, no pattern from the circularity taxonomy applies at load-bearing strength.

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

ConFL introduces no physical or natural entities. The CKB and interaction DSL are software artifacts, not postulated external things requiring independent falsifiable evidence. The analysis rests on domain assumptions about static identification of concurrency constructs, software modularity, analysis soundness, and label quality.

assumptions (4)
  • domain assumption Thread entry points can be identified statically from syntactic patterns such as explicit Thread creation, Executor submissions, asynchronous callbacks, and framework-managed entry methods.
    Section 4.1 relies on this identification to define the interaction DSL and CKB. Section 6.1 admits that third-party library concurrency is missed, limiting completeness.
  • domain assumption Well-engineered systems have high cohesion and low coupling, so component and package boundaries are informative for narrowing the search space.
    Section 4.3 justifies the hierarchy-guided strategy with this structural assumption. If software is not organized this way, early retrieval decisions lose their value.
  • domain assumption The static analysis is sound because the call graph includes all virtual dispatch targets and shared variable abstraction covers all fields and parameters.
    Theorem 4.2 states this soundness, but the implementation uses JavaParser and Datalog without pointer or alias analysis, and Section 6.1 acknowledges CKB noise from over-approximation.
  • domain assumption Ground-truth faulty methods are correctly identified from bug-fixing commits.
    Section 5.1.1 states that ground-truth faulty methods are identified from fix commits. Incorrect or coarse labels would distort all reported metrics.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ConFL: Explainable Concurrent Fault Localization via Hierarchy-Guided LLM Reasoning." pith.science (2026). https://pith.science/paper/GAG4YUGF

@misc{pith2026260802974,
  author       = {Pith},
  title        = {Pith review of: ConFL: Explainable Concurrent Fault Localization via Hierarchy-Guided LLM Reasoning},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GAG4YUGF}},
  note         = {Machine review of arXiv:2608.02974}
}
read the original abstract

Localizing concurrent bugs from bug reports alone is challenging due to incomplete information, misleading program-entity mentions, and complex cross-thread interactions, causing existing LLM-based approaches to suffer from unstable reasoning and limited explainability. We propose ConFL, an explainable concurrent fault localization framework that augments LLM reasoning with structured concurrency knowledge. ConFL constructs a Concurrent Knowledge Base (CKB) from source code and performs LLM-guided hierarchical retrieval to progressively narrow the search space from components to interaction-level concurrency contexts. An interaction-level DSL explicitly encodes cross-thread interactions over shared resources, enabling focused reasoning without traversing deep call chains. Experiments on real-world concurrent bugs from eight large-scale Java projects show that ConFL significantly outperforms state-of-the-art IR-based and LLM-based baselines, achieving an MRR of 0.503 and a MAP of 0.486, while remaining robust to noisy bug reports, unseen bugs, and different LLM backbones.

Figures

Figures reproduced from arXiv: 2608.02974 by the authors.

Figure 1
Figure 1. The overview of ConFL. first extracts concurrency-relevant information from source code and organizes it into a Concurrent Knowledge Base (CKB). The CKB captures concurrency semantics at multiple abstraction levels, including components, packages, thread entry points, methods, and interaction-level behaviors. Fault localization is then carried out as a progressive refinement process. Starting from the bug report, an… view at source ↗
Figure 2
Figure 2. Interaction DSL Based on these extracted entities, we define an interaction DSL to represent potential concurrent behaviors [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Prompt Template Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA077. Publication date: October 2026 [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Accuracy of Hierarchy As shown in [PITH_FULL_IMAGE:figures/full_fig_p016_4.png]
Figure 5
Figure 5. Figure 5: Performance across LLMs Interestingly, newer or larger models do not consistently improve localization performance. We hypothesize that this behavior is related to differences in reasoning style and adher￾ence to the hierarchy-guided retrieval process. Models such as G…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 9 canonical work pages

  1. [1]

    Rui Abreu, Peter Zoeteweij, Rob Golsteijn, and Arjan JC Van Gemund. 2009. A practical evaluation of spectrum-based fault localization.Journal of Systems and Software82, 11 (2009), 1780–1792. doi:10.1016/j.jss.2009.06.035

  2. [2]

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

  3. [3]

    Aritra Bandyopadhyay and Sudipto Ghosh. 2011. Proximity based weighting of test cases to improve spectrum based fault localization. In2011 26th IEEE/ACM International Conference on Automated Software Engineering (ASE 2011). IEEE, 420–423. doi:10.1109/ASE.2011.6100088

  4. [4]

    Sam Blackshear, Nikos Gorogiannis, Peter W O’Hearn, and Ilya Sergey. 2018. RacerD: compositional static race detection.Proceedings of the ACM on Programming Languages2, OOPSLA (2018), 1–28. doi:10.1145/3276514

  5. [5]

    Partha Chakraborty, Mahmoud Alfadel, and Meiyappan Nagappan. 2024. Rlocator: Reinforcement learning for bug localization.IEEE Transactions on Software Engineering50, 10 (2024), 2695–2708. doi:10.1109/TSE.2024.3452595

  6. [7]

    Justin Chu, Tingting Yu, Jane Huffman Hayes, Xue Han, and Yu Zhao. 2022. Effective fault localization and context-aware debugging for concurrent programs.Software Testing, Verification and Reliability32, 1 (2022), e1797. doi:10.1002/stvr.1797

  7. [8]

    Ali Ghanbari, Deepak-George Thomas, Muhammad Arbab Arshad, and Hridesh Rajan. 2023. Mutation-based fault localization of deep neural networks. In2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 1301–1313. doi:10.1109/ASE56229.2023.00171

  8. [9]

    James A Jones and Mary Jean Harrold. 2005. Empirical evaluation of the tarantula automatic fault-localization technique. InProceedings of the 20th IEEE/ACM international Conference on Automated software engineering. 273–282. doi:10.1145/1101908.1101949

Show all 31 references
  1. [10]

    James A Jones, Mary Jean Harrold, and John Stasko. 2002. Visualization of test information to assist fault localization. InProceedings of the 24th international conference on Software engineering. 467–477. doi:10.1145/581396.581397

  2. [11]

    Sungmin Kang, Gabin An, and Shin Yoo. 2024. A quantitative and qualitative evaluation of LLM-based explainable fault localization.Proceedings of the ACM on Software Engineering1, FSE (2024), 1424–1446. doi:10.1145/3660771

  3. [12]

    Jaekwon Lee, Dongsun Kim, Tegawendé F Bissyandé, Woosung Jung, and Yves Le Traon. 2018. Bench4bl: reproducibility study on the performance of ir-based bug localization. InProceedings of the 27th ACM SIGSOFT international symposium on software testing and analysis. 61–72. doi:1...

  4. [13]

    Xia Li, Wei Li, Yuqun Zhang, and Lingming Zhang. 2019. Deepfl: Integrating multiple fault diagnosis dimensions for deep fault localization. InProceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis. 169–180. doi:10.1145/3293882.3330574

  5. [14]

    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. InProceedings of the 29th ACM joint meeting on european software engineering conference and sy...

  6. [15]

    Mayur Naik, Alex Aiken, and John Whaley. 2006. Effective static race detection for Java. InProceedings of the 27th ACM SIGPLAN Conference on Programming Language Design and Implementation. 308–319. doi:10.1145/1133255.1134018

  7. [16]

    Mike Papadakis and Yves Le Traon. 2015. Metallaxis-FL: mutation-based fault localization.Software Testing, Verification and Reliability25, 5-7 (2015), 605–628. doi:10.1002/stvr.1509

  8. [17]

    Sangmin Park, Richard Vuduc, and Mary Jean Harrold. 2012. A unified approach for localizing non-deadlock concur- rency bugs. InSoftware Testing, Verification and Validation (ICST), 2012 IEEE Fifth International Conference on. 51–60. doi:10.1109/ICST.2012.85

  9. [18]

    Sangmin Park, Richard W Vuduc, and Mary Jean Harrold. 2010. Falcon: fault localization in concurrent programs. In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering-Volume 1. 245–254. doi:10.1145/ 1806799.1806838

  10. [19]

    Binhang Qi, Hailong Sun, Wei Yuan, Hongyu Zhang, and Xiangxin Meng. 2021. Dreamloc: A deep relevance matching- based framework for bug localization.IEEE Transactions on Reliability71, 1 (2021), 235–249. doi:10.1109/TR.2021.3104728

  11. [20]

    Yihao Qin, Shangwen Wang, Yiling Lou, Jinhao Dong, Kaixin Wang, Xiaoling Li, and Xiaoguang Mao. 2024. Agentfl: Scaling llm-based fault localization to project-level context.arXiv preprint arXiv:2403.16362(2024). doi:10.48550/arXiv. 2403.16362

  12. [21]

    Mohammad Masudur Rahman and Chanchal K Roy. 2018. Improving ir-based bug localization with context-aware query reformulation. InProceedings of the 2018 26th ACM joint meeting on European software engineering conference and symposium on the foundations of software engineering. ...

  13. [22]

    Abdul Razzaq, Jim Buckley, James Vincent Patten, Muslim Chochlov, and Ashish Rajendra Sai. 2021. BoostNSift: A query boosting and code sifting technique for method level bug localization. In2021 IEEE 21st International Working Conference on Source Code Analysis and Manipulatio...

  14. [23]

    Raul Santelices, James A Jones, Yanbing Yu, and Mary Jean Harrold. 2009. Lightweight fault-localization using multiple coverage types. InSoftware Engineering, 2009. ICSE 2009. IEEE 31st International Conference on. 56–66. doi:10.1109/ICSE. 2009.5070508

  15. [24]

    Shuai Shao, Lu Xiao, and Tingting Yu. 2026. Identifying Concurrency Bug Reports via Linguistic Patterns.arXiv preprint arXiv:2601.16338(2026). doi:10.48550/arXiv.2601.16338

  16. [25]

    Shuai Shao and Tingting Yu. 2023. Information retrieval-based fault localization for concurrent programs. In2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 1467–1479. doi:10.1109/ASE56229. 2023.00122

  17. [26]

    Shuai Shao and Tingting Yu. 2024. Enhancing IR-based Fault Localization using Large Language Models.arXiv preprint arXiv:2412.03754(2024). doi:10.48550/arXiv.2412.03754

  18. [27]

    Chu-Pan Wong, Yingfei Xiong, Hongyu Zhang, Dan Hao, Lu Zhang, and Hong Mei. 2014. Boosting bug-report- oriented fault localization with segmentation and stack-trace analysis. In2014 IEEE international conference on software maintenance and evolution. IEEE, 181–190. doi:10.1109...

  19. [28]

    W Eric Wong, Vidroha Debroy, Ruizhi Gao, and Yihao Li. 2013. The DStar method for effective software fault localization.IEEE Transactions on Reliability63, 1 (2013), 290–308. doi:10.1109/TR.2013.2285319

  20. [29]

    W Eric Wong, Vidroha Debroy, Yihao Li, and Ruizhi Gao. 2012. Software fault localization using dstar (d*). In2012 IEEE Sixth International Conference on Software Security and Reliability. IEEE, 21–30. doi:10.1109/SERE.2012.12

  21. [30]

    Chuyang Xu, Zhongxin Liu, Xiaoxue Ren, Gehao Zhang, Ming Liang, and David Lo. 2025. Flexfl: Flexible and effective fault localization with open-source large language models.IEEE Transactions on Software Engineering(2025). doi:10.1109/TSE.2025.3553363

  22. [31]

    Yanbing Yu, James A Jones, and Mary Jean Harrold. 2008. An empirical study of the effects of test-suite reduction on fault localization. InProceedings of the 30th international conference on Software engineering. 201–210. doi:10.1145/ 1368088.1368116

  23. [32]

    Wei Zhang, Junghee Lim, Ramya Olichandran, Joel Scherpelz, Guoliang Jin, Shan Lu, and Thomas Reps. 2011. ConSeq: detecting concurrency bugs through sequential errors. InACM SIGPLAN Notices, Vol. 46. 251–264. doi:10.1145/1961296. 1950395 Received 2026-01-30; accepted 2026-06-25...

Pith tools

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