Pith. sign in

REVIEW 3 major objections 5 minor 77 references

KernelDiag: Agent-Based Root Cause Diagnosis for Kernel Crashes

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

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

Pith's one-line read Kernel crash root causes can be localized by aligning syscalls, logs, and crash reports into a shared causal evidence graph.

desk verdict Solid system paper with real value, but the headline comparison is confounded because KernelDiag gets syscalls and logs while the baselines get only crash/issue reports — a same-input ablation is needed before the strongest claims stand. read the letter →

arxiv 2607.17722 v1 pith:CFQUBG2O submitted 2026-07-20 cs.SE

Weijing Wang , Zan Wang , Dong Wang , Haichi Wang , Junjie Chen This is my paper
classification cs.SE
keywords kernelcrashdiagnosisrootcauseanalysisLLMagentsevidencegraphlog-to-codemappingfaultlocalizationLinuxcausalreasoning
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

KernelDiag sets out to prove that Linux kernel crash diagnosis, today a manual bottleneck, can be automated by treating the problem as structured causal reasoning instead of text matching. It claims that a crash's root cause is usually not at the crash site, and that the missing link can be recovered by aligning three sparse artifacts—triggering syscalls, runtime logs, and crash reports—into a common source-level representation that records how a bad state is born, propagates, and finally trips an invariant. The paper's evidence is a benchmark of 279 real-world crashes where the framework reportedly ranks the faulty file in the top 10 for 97% of cases and the faulty method for 70%, with the largest gains on the hardest cases that contain no explicit hint. If true, this would move kernel debugging from reading stack traces toward machine-generated causal narratives that point to the function whose logic should be fixed. The paper also proposes a concrete mechanism—the Evidence Graph—as the substrate for that reasoning.

What carries the argument

The Evidence Graph, a schema-validated directed graph of source-level entities and causal dependencies, is the object that carries the argument. It is supported by three mechanisms: log-to-code mapping, which formalizes logging identification as backward reachability from atomic logging primitives (functions whose bodies directly invoke printk) through macro-expansion layers, so that logs can be anchored to exact call sites; Semantic Function Introspection, which lets agents retrieve full function bodies, macro definitions, and struct declarations and resolve pointer-based field accesses to their owning kernel state; and Environment-Aware Semantic Pruning, which uses the kernel build configu

What would settle it

Run the baseline localizers with the same syscalls and logs that KernelDiag receives (or run KernelDiag with crash reports only) and check whether the reported 4x/2x no-hint gaps survive; also scale the post-training-cutoff evaluation beyond 50 crashes—if the file-level Top-10 advantage drops toward the baseline's level, the evidence graph is not the load-bearing component.

Watch

Extended reading notes

Core claim

KernelDiag's central claim is that a kernel crash's root cause can be recovered by structured causal reasoning over heterogeneous artifacts rather than by surface matching on the crash report. The framework's core move is to lift each artifact into a shared, source-grounded Evidence Graph: nodes name kernel entities (operations, data carriers, logical constraints) with their exact file/function/line locations, and edges record inferred dependencies such as data/control flow, lifecycle transitions, and logical provenance. Because every node carries source locations, graphs built from syscalls, logs, and reports can be aligned and merged. The paper reports that on a benchmark of 279 real-world

Load-bearing premise

The stated gains rest on the assumption that the causal evidence graph—not the extra syscalls and logs that KernelDiag consumes and the baselines do not—is what drives the improvement, and that the benchmark's historical bugs are not simply memorized by the LLM.

Editorial extensions

If this is right

  • Developers can be pointed to fewer than two candidate files on average for the studied crashes (mean first rank 1.93), turning crash triage from reading stack traces into verifying a ranked shortlist.
  • On no-hint cases—where the crash report does not even name the faulty location—the faulty file appears in the top 10 for 82.86% of crashes, versus 20% for the strongest baseline, and the faulty method for 34.78%, versus at most 17.39%.
  • Correct Top-1 localization is statistically associated with higher explanation usefulness and consistency (large effect size), so improving localization directly improves the actionability of the resulting diagnosis.
  • Because the approach is not dependent on one LLM (two different backends both outperform the baselines), the design appears portable across models and likely to improve further as the underlying models improve.

Reading between the lines

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

  • The evidence graph could double as a structured input for automated patch generation or for synthesizing minimal reproducer programs, since it already encodes the propagation chain from bad state to crash site.
  • The paper's own failure analysis (a framebuffer out-of-bounds case) suggests the approach hits a ceiling when the diagnostic artifacts lack an intermediate state update; adding lightweight dynamic instrumentation at suspicious points and feeding the result back into the graph is a direct testable extension.
  • Because the two studied LLM backends agree on only 59 of 93 method-level Top-1 hits, ensembling multiple backends (or routing cases by artifact type) is a cheap way to push accuracy further.
  • A controlled input-ablation comparison—handing the same syscalls and logs to the baseline localizers—would separate the contribution of the evidence-graph reasoning from the contribution of simply having more input artifacts.
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

3 major / 5 minor

Summary. The paper presents KernelDiag, an agent-based framework for root-cause diagnosis of Linux kernel crashes. KernelDiag preprocesses heterogeneous diagnostic artifacts (syscalls, runtime logs, crash reports), maps logs to source code via backward reachability over logging macros, then uses artifact-specialized agents that iteratively explore kernel source with function-introspection and configuration-pruning tools. The agents incrementally build schema-validated Evidence Graphs, which are used for coarse-to-fine file- and method-level localization and for generating causal explanations. The evaluation uses the 279-crash KGYM benchmark, a 50-crash post-release dataset, multiple ablations, LLM-assisted and human scoring of explanation quality, and two LLM backends. The paper claims that KernelDiag consistently outperforms LinuxFL+ and Agentless at both file and method levels, with particularly large gains on NoHint cases, and that its explanations are more accurate, coherent, and actionable.

Significance. If the central comparative claim is established under controlled conditions, this is a practically valuable contribution: it addresses a real bottleneck in kernel fuzzing workflows and proposes a concrete architecture (log-to-code mapping, artifact-specialized agents, Evidence Graphs) for combining sparse kernel evidence. The paper has notable strengths: a substantial evaluation corpus (279+50 crashes), explicit Hint/NoHint partitioning, ablation of core components, a post-release dataset that mitigates pre-training leakage concerns, public artifact release, and human evaluation with inter-rater agreement. However, the headline comparison is weakened by an input-availability asymmetry: KernelDiag receives syscalls, logs, and crash reports, while LinuxFL+ and Agentless receive only issue/crash report text. This makes the current evidence insufficient to attribute the observed gains specifically to Evidence-Graph causal reasoning rather than to the additional artifacts.

major comments (3)
  1. [§IV-D, Tables II–III] The central comparative claim is not established under equal input conditions. Section IV-D states that LinuxFL+ and Agentless are evaluated "under their original input assumptions, without manually injecting additional artifacts such as syscalls or runtime logs," while KernelDiag consumes syscalls, runtime logs, and crash reports. The observed gains in Tables II and III, including the headline 4x/2x NoHint improvements, could therefore be explained by additional input signals (e.g., an anomalous log line or a telling syscall sequence) rather than by Evidence-Graph causal reasoning. The Hint/NoHint partition in Section IV-A removes only explicit mentions of the ground-truth location; it does not remove implicit clues carried by the extra artifacts. A controlled comparison—e.g., baselines receiving the same syscall/log evidence, or KernelDiag run on crash reports alone in a matched condit
  2. [§V-C, Table VII] The ablation study removes artifacts from KernelDiag (w/oSyscall, w/oLog, w/oReport) but never adds artifacts to the baselines. These ablations show that each artifact contributes to KernelDiag and that removing the report is costly, but they do not answer whether the baseline gap in the main comparison is due to artifact availability. The w/oReport condition is closest to the baseline input setting, yet KernelDiag w/oReport (24.37% file-level Top@1) still differs from LinuxFL+ (51.61%) and Agentless (50.18%), likely because the pipelines differ. To attribute the advantage to Evidence-Graph reasoning, the authors should add syscalls and logs to the baselines (or otherwise equalize inputs) in at least one experimental condition.
  3. [§VI-I, Table IX] The post-release evaluation is a good check for pre-training leakage, but it does not address the input-availability confound: Table IX again compares KernelDiag on three artifact types against baselines on the issue report only. The statement that gains are "unlikely to arise from memorization" and instead from "structured reasoning over heterogeneous evidence sources" is not justified by this design, because the heterogeneous evidence sources themselves are not provided to the baselines. The post-release result would need the same equal-input control to support that attribution.
minor comments (5)
  1. [Figure 3(c)] The file label "include/linux/fs_context.c" appears suspicious; the definition of logfc is likely in fs/fs_context.c or the header include/linux/fs_context.h. Please verify and correct.
  2. [§IV-A] The description of Hint/NoHint says "explicitly mentioned in the diagnostic artifacts," but the implementation mentions regex-matching against "the artifacts." Clarify which artifact set is used for the partition (crash report only, or all three), since this affects interpretation of the NoHint results.
  3. [§V-A] Relative improvements such as "314.29% to 900.00%" over near-zero baselines are mathematically correct but can be misleading. Consider reporting absolute percentage-point differences alongside the relative percentages.
  4. [§IV-B] The claim that KernelDiag is "the first approach targeting kernel-level root-cause diagnosis" is strong given the existence of LinuxFL+, a kernel-specific fault diagnosis method. Qualify the claim (e.g., "first end-to-end kernel RCA with causal explanation") or soften it.
  5. [§VII] The Threats to Validity section does not mention the input-availability asymmetry between KernelDiag and the baselines. Even if the final paper does not add the equal-input experiment, this threat should be explicitly acknowledged and discussed.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: KernelDiag's localization output is an LLM-agent prediction evaluated against external ground truth, with no fitted parameter or derivation reducing to its own inputs.

full rationale

KernelDiag's claimed derivation chain is empirical rather than definitional. The system consumes crash reports, syscalls, runtime logs, kernel source, and .config, and its agents produce ranked faulty files/methods and Evidence Graphs, which are then evaluated against ground-truth patch locations from KGYM and a post-release dataset. No equation fits a parameter to the evaluation labels, and no 'prediction' is defined in terms of the target output. The Hint/NoHint partition is based on whether the ground-truth entity is explicitly mentioned in the diagnostic artifacts, which separates easy from hard cases but does not inject ground truth into KernelDiag's ranking. The RQ3 ablations remove components from KernelDiag and measure degradation against the same external labels, which is a standard component analysis. Cited prior work (KGYM, LinuxFL+, Agentless, SWE-agent) is external and not part of a self-citation chain; the paper invokes no author-imported uniqueness theorem or ansatz. The main validity concern is the comparison confound in Section IV-D: baselines are evaluated 'without manually injecting additional artifacts such as syscalls or runtime logs,' while KernelDiag uses all three artifact types. That is a fairness threat, not circularity, because KernelDiag's outputs are not constructed from the baseline results or from the ground-truth labels. Similarly, the acknowledged LLM pre-training leakage risk (Section VII) concerns contamination, not definitional circularity. No specific circular step can be exhibited, so the score is 0.

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

No fitted numeric parameters appear; the main free choices (K=10, three agent roles, temperature 0) follow prior work or implementation design rather than being tuned to KGYM. The load-bearing assumptions are static-analysis correctness, patch-derived ground truth, and faithful LLM reasoning. The Evidence Graph is the only invented conceptual entity, and it lacks independent external validation.

assumptions (4)
  • domain assumption Backward reachability from atomic printk sinks correctly identifies all logging-relevant functions and macros in the kernel.
    Foundation of log-to-code mapping in Section III-A; unverified static-analysis claim. False negatives would drop log evidence and undermine cross-artifact alignment.
  • domain assumption The crash-specific kernel .config plus static source code is sufficient to prune infeasible execution paths.
    Environment-Aware Semantic Pruning (Section III-B-II) assumes static artifacts capture runtime feasibility well enough to guide the agents toward the true path.
  • domain assumption KGYM's golden patch comments and fix locations accurately determine the ground-truth faulty file and method.
    All localization and explanation metrics depend on this external label; the paper does not independently verify patch-derived labels for ambiguous multi-method fixes.
  • domain assumption LLM-generated Evidence Graphs faithfully represent source-level facts and causal dependencies without fabrication.
    The agents' intermediate outputs are not validated per step; if the LLM hallucinates code facts, the final accuracy would degrade but the error would not be visible in the reported graphs.
invented entities (1)
  • Evidence Graph
    purpose: A structured node-edge representation of causal dependencies (Active Entities, Data Carriers, Logical Constraints) built by artifact-specialized agents to support cross-source alignment and localization.
    The Evidence Graph is an internal representation introduced by KernelDiag. It has no falsifiable handle outside the paper; its utility is only demonstrated indirectly through end-to-end system accuracy, so its causal claims are not independently testable.

how reviews work

0 comments
Cite this review

Pith. "Pith review of KernelDiag: Agent-Based Root Cause Diagnosis for Kernel Crashes." pith.science (2026). https://pith.science/paper/CFQUBG2O

@misc{pith2026260717722,
  author       = {Pith},
  title        = {Pith review of: KernelDiag: Agent-Based Root Cause Diagnosis for Kernel Crashes},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CFQUBG2O}},
  note         = {Machine review of arXiv:2607.17722}
}
read the original abstract

The Linux kernel is one of the most complex software systems, where automated fuzzing continuously exposes thousands of crashes, yet root-cause diagnosis remains a manual and time-consuming bottleneck. Existing LLM-based root cause analysis (RCA) techniques, effective for distributed systems, do not readily generalize to kernel debugging due to sparse low-level artifacts, heterogeneous diagnostic evidence (e.g., syscalls, logs, and crash reports), and complex non-linear fault propagation that demands fine-grained method-level reasoning. To address these challenges, we propose KernelDiag, an agent-based framework for kernel root-cause diagnosis via structured causal reasoning. KernelDiag first aligns heterogeneous diagnostic artifacts through log-to-code mapping, and then employs artifact-specialized agents to iteratively reason over source-level program semantics and crash-specific kernel configurations. The inferred causal dependencies are incrementally organized into structured Evidence Graphs, enabling accurate faulty-method localization and causal explanations. We evaluate KernelDiag on the real-world KGYM benchmark. KernelDiag consistently outperforms state-of-the-art localization approaches at both file and method levels, achieving significant improvements in Top@k accuracy, including up to 4x and 2x gains in challenging settings without explicit hints. Furthermore, both human and LLM-assisted evaluations show that KernelDiag generates accurate, coherent, and actionable diagnostic explanations. Overall, this work lays the foundation for automated kernel root-cause diagnosis by bridging low-level diagnostic evidence with source-level causal reasoning.

Figures

Figures reproduced from arXiv: 2607.17722 by the authors.

Figure 1
Figure 1. An example of a real-world kernel crash indicates that __ext4_fill_super fails to validate the metadata state, allows a corrupted superblock to persist, and eventually triggers a BUG() in ext4_es_cache_extent. However, the crash report in [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Overview of KernelDiag heavily macro-encapsulated, with subsystem-specific wrappers obscuring logging intent [32] [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. An example of a kernel logging macro hidden behind multi-layer [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: An example of causal topology structure of Evidence Graphs [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: The example root-cause explanation generated by KernelDiag [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 6
Figure 6. Figure 6: A failure diagnosis by KernelDiag closed-source LLMs are not transparent, data leakage cannot be completely ruled out. External Validity. Our experiments are mainly conducted on KGYM, which covers diverse real-world Linux kernel crashes. Nevertheless, KGYM may not full…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

77 extracted references · 2 linked inside Pith

  1. [1]

    The Linux Kernel Archives,

    The Linux Kernel Organization, “The Linux Kernel Archives,” https: //www.kernel.org/, 2026, accessed: 2026-03-26

    2026

  2. [2]

    An empirical study of test case prioritization on the linux kernel,

    H. Wang, R. Yu, D. Wang, Y . Du, Y . Zhao, J. Chen, and Z. Wang, “An empirical study of test case prioritization on the linux kernel,”Automated Software Engineering, vol. 32, no. 2, p. 49, 2025

    2025

  3. [3]

    Linux kernel surpasses 40 million lines of code,

    Stackscale, “Linux kernel surpasses 40 million lines of code,” https://www.stackscale.com/blog/ linux-kernel-surpasses-40-million-lines-code, 2024, accessed: 2026- 03-18

    2024

  4. [4]

    syzkaller: an unsupervised coverage-guided kernel fuzzer,

    Google, “syzkaller: an unsupervised coverage-guided kernel fuzzer,” https://github.com/google/syzkaller, 2015, accessed: 2026-03-18

    2015

  5. [5]

    “Syzbot,” https://syzkaller.appspot.com, 2025

    2025

  6. [6]

    Yesterday once more: facilitating linux kernel bug reproduction via reverse fuzzing,

    X. Li, Y . Kang, C. Wu, D. Liu, J. Wang, Y . Sun, Z. Wu, Y . Wang, R. Ma, and Q. Wei, “Yesterday once more: facilitating linux kernel bug reproduction via reverse fuzzing,”IEEE TIFS, 2025

    2025

  7. [7]

    Grebe: Unveiling exploitation potential for linux kernel bugs,

    Z. Lin, Y . Chen, Y . Wu, D. Mu, C. Yu, X. Xing, and K. Li, “Grebe: Unveiling exploitation potential for linux kernel bugs,” in2022 IEEE Symposium on Security and Privacy (SP). IEEE, 2022, pp. 2078–2095

    2022

  8. [8]

    Causal inference-based root cause analysis for online service systems with intervention recognition,

    M. Li, Z. Li, K. Yin, X. Nie, W. Zhang, K. Sui, and D. Pei, “Causal inference-based root cause analysis for online service systems with intervention recognition,” inProceedings of ACM SIGKDD (KDD), 2022, pp. 3230–3240

    2022

Show all 77 references
  1. [9]

    Causalrca: Causal inference based pre- cise fine-grained root cause localization for microservice applications,

    R. Xin, P. Chen, and Z. Zhao, “Causalrca: Causal inference based pre- cise fine-grained root cause localization for microservice applications,” Journal of Systems and Software, vol. 203, p. 111724, 2023

    2023

  2. [10]

    Automatic root cause analysis via large language models for cloud incidents,

    Y . Chen, H. Xie, M. Ma, Y . Kang, X. Gao, L. Shi, Y . Cao, X. Gao, H. Fan, M. Wen, J. Zeng, S. Ghosh, X. Zhang, C. Zhang, Q. Lin, S. Rajmohan, D. Zhang, and T. Xu, “Automatic root cause analysis via large language models for cloud incidents,” inProceedings of EuroSys, 2024, p...

    2024

  3. [11]

    React: Synergizing reasoning and acting in language models,

    S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. R. Narasimhan, and Y . Cao, “React: Synergizing reasoning and acting in language models,” inProceedings of ICLR, 2022

    2022

  4. [12]

    Exploring llm-based agents for root cause analysis,

    D. Roy, X. Zhang, R. Bhave, C. Bansal, P. Las-Casas, R. Fonseca, and S. Rajmohan, “Exploring llm-based agents for root cause analysis,” in Proceedings of FSE, 2024, pp. 208–219

    2024

  5. [13]

    Rcagent: Cloud root cause analysis by autonomous agents with tool-augmented large language models,

    Z. Wang, Z. Liu, Y . Zhang, A. Zhong, J. Wang, F. Yin, L. Fan, L. Wu, and Q. Wen, “Rcagent: Cloud root cause analysis by autonomous agents with tool-augmented large language models,” inProceedings of CIKM, 2024, pp. 4966–4974

    2024

  6. [14]

    Openrca: Can large language models locate the root cause of software failures?

    J. Xu, Q. Zhang, Z. Zhong, S. He, C. Zhang, Q. Lin, D. Pei, P. He, D. Zhang, and Q. Zhang, “Openrca: Can large language models locate the root cause of software failures?” inProceedings of ICLR, 2025

    2025

  7. [15]

    Kgym: A platform and dataset to benchmark large language models on linux kernel crash resolution,

    A. Mathai, C. Huang, P. Maniatis, A. Nogikh, F. Ivan ˇci´c, J. Yang, and B. Ray, “Kgym: A platform and dataset to benchmark large language models on linux kernel crash resolution,”Advances in Neural Information Processing Systems, vol. 37, pp. 78 053–78 078, 2024

    2024

  8. [16]

    Taming system complexity: Demystifying software engineering agents in diagnosing linux kernel faults,

    Z. Zhou, Z. Huang, Y . He, C. Wang, J. Wang, Y . Wu, X. Peng, and Y . Lou, “Taming system complexity: Demystifying software engineering agents in diagnosing linux kernel faults,” inProceedings of ACL, 2026, pp. 18 899–18 916

    2026

  9. [17]

    Scalalog: Scalable log-based failure diagnosis using llm,

    L. Zhang, T. Jia, M. Jia, Y . Wu, H. Liu, and Y . Li, “Scalalog: Scalable log-based failure diagnosis using llm,” inProceedings of ICASSP. IEEE, 2025, pp. 1–5

    2025

  10. [18]

    Logkg: Log failure diagnosis through knowledge graph,

    Y . Sui, Y . Zhang, J. Sun, T. Xu, S. Zhang, Z. Li, Y . Sun, F. Guo, J. Shen, Y . Zhanget al., “Logkg: Log failure diagnosis through knowledge graph,”IEEE Transactions on Services Computing, vol. 16, no. 5, pp. 3493–3507, 2023

    2023

  11. [19]

    Multivariate log- based anomaly detection for distributed database,

    L. Zhang, T. Jia, M. Jia, Y . Li, Y . Yang, and Z. Wu, “Multivariate log- based anomaly detection for distributed database,” inProceedings of ACM SIGKDD (KDD), 2024, pp. 4256–4267

    2024

  12. [20]

    Practical root cause localization for microservice systems via trace analysis,

    Z. Li, J. Chen, R. Jiao, N. Zhao, Z. Wang, S. Zhang, Y . Wu, L. Jiang, L. Yan, Z. Wanget al., “Practical root cause localization for microservice systems via trace analysis,” inProceedings of IWQOS. IEEE, 2021, pp. 1–10

    2021

  13. [21]

    Microhecl: High-efficient root cause localization in large-scale microservice systems,

    D. Liu, C. He, X. Peng, F. Lin, C. Zhang, S. Gong, Z. Li, J. Ou, and Z. Wu, “Microhecl: High-efficient root cause localization in large-scale microservice systems,” inProceedings of ICSE-SEIP. IEEE, 2021, pp. 338–347

    2021

  14. [22]

    Unsupervised anomaly detection on microservice traces through graph vae,

    Z. Xie, H. Xu, W. Chen, W. Li, H. Jiang, L. Su, H. Wang, and D. Pei, “Unsupervised anomaly detection on microservice traces through graph vae,” inProceedings of the ACM Web Conference, 2023, pp. 2874–2884

    2023

  15. [23]

    Traceark: Towards actionable performance anomaly alerting for online service systems,

    Z. Zeng, Y . Zhang, Y . Xu, M. Ma, B. Qiao, W. Zou, Q. Chen, M. Zhang, X. Zhang, H. Zhanget al., “Traceark: Towards actionable performance anomaly alerting for online service systems,” inProceedings of ICSE- SEIP. IEEE, 2023, pp. 258–269

    2023

  16. [24]

    Nezha: Interpretable fine-grained root causes analysis for microservices on multi-modal observability data,

    G. Yu, P. Chen, Y . Li, H. Chen, X. Li, and Z. Zheng, “Nezha: Interpretable fine-grained root causes analysis for microservices on multi-modal observability data,” inProceedings of ESEC/FSE, 2023, pp. 553–565

    2023

  17. [25]

    Demystifying llm-based software engineering agents,

    C. S. Xia, Y . Deng, S. Dunn, and L. Zhang, “Demystifying llm-based software engineering agents,”Proceedings of the ACM on Software Engineering, vol. 2, no. FSE, pp. 801–824, 2025

    2025

  18. [26]

    KernelDiag-Artifact,

    “KernelDiag-Artifact,” Accessed: 2026. [Online]. Available: https: //github.com/VikingStudyHard/KernelDiag-Artifact

    2026

  19. [27]

    Coca: Generative root cause analysis for distributed systems with code knowledge,

    Y . Li, Y . Wu, J. Liu, Z. Jiang, Z. Chen, G. Yu, and M. R. Lyu, “Coca: Generative root cause analysis for distributed systems with code knowledge,” inProceedings of ICSE. IEEE, 2025, pp. 1346–1358. 15

    2025

  20. [28]

    Towards intelligent incident management: why we need it and how we make it,

    Z. Chen, Y . Kang, L. Li, X. Zhang, H. Zhang, H. Xu, Y . Zhou, L. Yang, J. Sun, Z. Xuet al., “Towards intelligent incident management: why we need it and how we make it,” inProceedings of ESEC/FSE, 2020, pp. 1487–1497

    2020

  21. [29]

    Syzdescribe: Principled, automated, static generation of syscall descriptions for kernel drivers,

    Y . Hao, G. Li, X. Zou, W. Chen, S. Zhu, Z. Qian, and A. A. Sani, “Syzdescribe: Principled, automated, static generation of syscall descriptions for kernel drivers,” inIEEE S&P. IEEE, 2023, pp. 3262– 3278

    2023

  22. [30]

    An empirical study on language models for generating log statements in test code,

    H. Shu, D. Wang, A. Mastropaolo, G. Bavota, and Y . Kamei, “An empirical study on language models for generating log statements in test code,”ACM TOSEM, 2025

    2025

  23. [31]

    Autolog: A log sequence synthesis framework for anomaly detection,

    Y . Huo, Y . Li, Y . Su, P. He, Z. Xie, and M. R. Lyu, “Autolog: A log sequence synthesis framework for anomaly detection,” inProceedings of ASE. IEEE, 2023, pp. 497–509

    2023

  24. [32]

    The sense of logging in the linux kernel,

    K. Patel, J. Faccin, A. Hamou-Lhadj, and I. Nunes, “The sense of logging in the linux kernel,”Empirical Software Engineering, vol. 27, no. 6, p. 153, 2022

    2022

  25. [33]

    An empirical study of fault localization families and their combinations,

    D. Zou, J. Liang, Y . Xiong, M. D. Ernst, and L. Zhang, “An empirical study of fault localization families and their combinations,”IEEE TSE, vol. 47, no. 2, pp. 332–347, 2019

    2019

  26. [34]

    Historical spectrum based fault localization,

    M. Wen, J. Chen, Y . Tian, R. Wu, D. Hao, S. Han, and S.-C. Cheung, “Historical spectrum based fault localization,”IEEE TSE, vol. 47, no. 11, pp. 2348–2368, 2019

    2019

  27. [35]

    An analysis and survey of the development of mutation testing,

    Y . Jia and M. Harman, “An analysis and survey of the development of mutation testing,”IEEE TSE, vol. 37, no. 5, pp. 649–678, 2010

    2010

  28. [36]

    Using mutation analysis for assessing and comparing testing coverage criteria,

    J. H. Andrews, L. C. Briand, Y . Labiche, and A. S. Namin, “Using mutation analysis for assessing and comparing testing coverage criteria,” IEEE TSE, vol. 32, no. 8, pp. 608–624, 2006

    2006

  29. [37]

    Information retrieval-based techniques for software fault localization,

    X. Xia and D. Lo, “Information retrieval-based techniques for software fault localization,”Handbook of Software Fault Localization: Founda- tions and Advances, pp. 365–391, 2023

    2023

  30. [38]

    Finelocator: A novel approach to method-level fine-grained bug localization by query expansion,

    W. Zhang, Z. Li, Q. Wang, and J. Li, “Finelocator: A novel approach to method-level fine-grained bug localization by query expansion,” Information and Software Technology, vol. 110, pp. 121–135, 2019

    2019

  31. [39]

    Pathidea: Improving information retrieval-based bug localization by re-constructing execution paths using logs,

    A. R. Chen, T.-H. Chen, and S. Wang, “Pathidea: Improving information retrieval-based bug localization by re-constructing execution paths using logs,”IEEE TSE, vol. 48, no. 8, pp. 2905–2919, 2021

    2021

  32. [40]

    Locagent: Graph-guided llm agents for code localization,

    Z. Chen, R. Tang, G. Deng, F. Wu, J. Wu, Z. Jiang, V . Prasanna, A. Cohan, and X. Wang, “Locagent: Graph-guided llm agents for code localization,” inProceedings of ACL, 2025, pp. 8697–8727

    2025

  33. [41]

    Swe-agent: Agent-computer interfaces enable automated soft- ware engineering,

    J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “Swe-agent: Agent-computer interfaces enable automated soft- ware engineering,”Advances in Neural Information Processing Systems, vol. 37, pp. 50 528–50 652, 2024

    2024

  34. [42]

    SWE-bench: Can language models resolve real- world github issues?

    C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. R. Narasimhan, “SWE-bench: Can language models resolve real- world github issues?” inProceedings of ICLR, 2024

    2024

  35. [43]

    Deepfl: Integrating multiple fault diagnosis dimensions for deep fault localization,

    X. Li, W. Li, Y . Zhang, and L. Zhang, “Deepfl: Integrating multiple fault diagnosis dimensions for deep fault localization,” inProceedings of ISSTA. ACM, 2019, pp. 169–180

    2019

  36. [44]

    Weighted kappa: Nominal scale agreement provision for scaled disagreement or partial credit

    J. Cohen, “Weighted kappa: Nominal scale agreement provision for scaled disagreement or partial credit.”Psychological bulletin, vol. 70, no. 4, p. 213, 1968

    1968

  37. [45]

    Fault localization with code coverage representation learning,

    Y . Li, S. Wang, and T. Nguyen, “Fault localization with code coverage representation learning,” inProceedings of ICSE. IEEE, 2021, pp. 661–673

    2021

  38. [46]

    Bleu: a method for automatic evaluation of machine translation,

    K. Papineni, S. Roukos, T. Ward, and W.-J. Zhu, “Bleu: a method for automatic evaluation of machine translation,” inProceedings of ACL, 2002, pp. 311–318

    2002

  39. [47]

    Rouge: A package for automatic evaluation of summaries,

    C.-Y . Lin, “Rouge: A package for automatic evaluation of summaries,” inText summarization branches out, 2004, pp. 74–81

    2004

  40. [48]

    Deep assessment of code review generation approaches: Beyond lexical similarity,

    Y . Jiang, H. Liu, T. Chen, F. Fan, C. Dong, K. Liu, and L. Zhang, “Deep assessment of code review generation approaches: Beyond lexical similarity,”arXiv preprint arXiv:2501.05176, 2025

    2025 arXiv

  41. [49]

    Deepcrceval: Revisiting the evaluation of code review comment generation,

    J. Lu, X. Li, Z. Hua, L. Yu, S. Cheng, L. Yang, F. Zhang, and C. Zuo, “Deepcrceval: Revisiting the evaluation of code review comment generation,” inInternational Conference on Fundamental Approaches to Software Engineering. Springer, 2025, pp. 43–64

    2025

  42. [50]

    Bitsai-cr: Automated code review via llm in practice,

    T. Sun, J. Xu, Y . Li, Z. Yan, G. Zhang, L. Xie, L. Geng, Z. Wang, Y . Chen, Q. Linet al., “Bitsai-cr: Automated code review via llm in practice,” inProceedings of FSE, 2025, pp. 274–285

    2025

  43. [51]

    Code review automation: strengths and weaknesses of the state of the art,

    R. Tufano, O. Dabi ´c, A. Mastropaolo, M. Ciniselli, and G. Bavota, “Code review automation: strengths and weaknesses of the state of the art,”IEEE TSE, vol. 50, no. 2, pp. 338–353, 2024

    2024

  44. [52]

    Deepseek-v3 technical report,

    A. Liu, B. Feng, B. Xue, B. Wang, B. Wu, C. Lu, C. Zhao, C. Deng, C. Zhang, C. Ruanet al., “Deepseek-v3 technical report,”arXiv preprint arXiv:2412.19437, 2024

    2024 arXiv

  45. [53]

    Large language models for equivalent mutant detection: How far are we?

    Z. Tian, H. Shu, D. Wang, X. Cao, Y . Kamei, and J. Chen, “Large language models for equivalent mutant detection: How far are we?” in Proceedings of ISSTA, 2024, pp. 1733–1745

    2024

  46. [54]

    Statistical comparisons of classifiers over multiple data sets,

    J. Demšar, “Statistical comparisons of classifiers over multiple data sets,” Journal of Machine Learning Research, vol. 7, pp. 1–30, 2006

    2006

  47. [55]

    Individual comparisons by ranking methods,

    F. Wilcoxon, “Individual comparisons by ranking methods,”Biometrics bulletin, vol. 1, no. 6, pp. 80–83, 1945

    1945

  48. [56]

    Issue-oriented agent-based framework for automated review comment generation,

    S. Li, D. Wang, P. Thongtanunam, Z. Wang, J. Yu, and J. Chen, “Issue-oriented agent-based framework for automated review comment generation,”ACM TOSEM, 2025

    2025

  49. [57]

    Krippendorff,Content analysis: An introduction to its methodology

    K. Krippendorff,Content analysis: An introduction to its methodology. Sage publications, 2018

    2018

  50. [58]

    Automating qualitative data analysis with large language models,

    A. Parfenova, A. Denzler, and J. Pfeffer, “Automating qualitative data analysis with large language models,” inProceedings of ACL, 2024, pp. 83–91

    2024

  51. [59]

    Toxigen: A large-scale machine-generated dataset for adversarial and implicit hate speech detection,

    T. Hartvigsen, S. Gabriel, H. Palangi, M. Sap, D. Ray, and E. Kamar, “Toxigen: A large-scale machine-generated dataset for adversarial and implicit hate speech detection,” inProceedings of ACL, 2022, pp. 3309– 3326

    2022

  52. [60]

    On a test of whether one of two random variables is stochastically larger than the other,

    H. B. Mann and D. R. Whitney, “On a test of whether one of two random variables is stochastically larger than the other,”The annals of mathematical statistics, pp. 50–60, 1947

    1947

  53. [61]

    A simple sequentially rejective multiple test procedure,

    S. Holm, “A simple sequentially rejective multiple test procedure,” Scandinavian journal of statistics, pp. 65–70, 1979

    1979

  54. [62]

    Dominance statistics: Ordinal analyses to answer ordinal questions

    N. Cliff, “Dominance statistics: Ordinal analyses to answer ordinal questions.”Psychological bulletin, vol. 114, no. 3, p. 494, 1993

    1993

  55. [63]

    Qwen3-max: Just scale it,

    Q. Team, “Qwen3-max: Just scale it,” September 2025

    2025

  56. [64]

    Boost- nsift: A query boosting and code sifting technique for method level bug localization,

    A. Razzaq, J. Buckley, J. V . Patten, M. Chochlov, and A. R. Sai, “Boost- nsift: A query boosting and code sifting technique for method level bug localization,” in2021 IEEE 21st International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE, 2021, pp. 81–91

    2021

  57. [65]

    Anomaly detection and failure root cause analysis in (micro) service-based cloud applications: A survey,

    J. Soldani and A. Brogi, “Anomaly detection and failure root cause analysis in (micro) service-based cloud applications: A survey,”ACM Computing Surveys (CSUR), vol. 55, no. 3, pp. 1–39, 2022

    2022

  58. [66]

    Log clustering based problem identification for online service systems,

    Q. Lin, H. Zhang, J.-G. Lou, Y . Zhang, and X. Chen, “Log clustering based problem identification for online service systems,” inProceedings of ICSE, 2016, pp. 102–111

    2016

  59. [67]

    Log filtering and interpretation for root cause analysis,

    H. Zawawy, K. Kontogiannis, and J. Mylopoulos, “Log filtering and interpretation for root cause analysis,” in2010 IEEE International Conference on Software Maintenance. IEEE, 2010, pp. 1–5

    2010

  60. [68]

    Graph-based trace analysis for microservice architecture understanding and problem diagnosis,

    X. Guo, X. Peng, H. Wang, W. Li, H. Jiang, D. Ding, T. Xie, and L. Su, “Graph-based trace analysis for microservice architecture understanding and problem diagnosis,” inProceedings of ESEC/FSE, 2020, pp. 1387– 1397

    2020

  61. [69]

    Actionable and interpretable fault localization for recurring failures in online service systems,

    Z. Li, N. Zhao, M. Li, X. Lu, L. Wang, D. Chang, X. Nie, L. Cao, W. Zhang, K. Suiet al., “Actionable and interpretable fault localization for recurring failures in online service systems,” inProceedings of ESEC/FSE, 2022, pp. 996–1008

    2022

  62. [70]

    Diagnosing root causes of intermittent slow queries in cloud databases,

    M. Ma, Z. Yin, S. Zhang, S. Wang, C. Zheng, X. Jiang, H. Hu, C. Luo, Y . Li, N. Qiuet al., “Diagnosing root causes of intermittent slow queries in cloud databases,”Proceedings of the VLDB Endowment, vol. 13, no. 8, pp. 1176–1189, 2020

    2020

  63. [71]

    Mulan: Multi-modal causal structure learning and root cause analysis for microservice systems,

    L. Zheng, Z. Chen, J. He, and H. Chen, “Mulan: Multi-modal causal structure learning and root cause analysis for microservice systems,” in Proceedings of the ACM Web Conference 2024, 2024, pp. 4107–4116

    2024

  64. [72]

    Micro- diag: Fine-grained performance diagnosis for microservice systems,

    L. Wu, J. Tordsson, J. Bogatinovski, E. Elmroth, and O. Kao, “Micro- diag: Fine-grained performance diagnosis for microservice systems,” in 2021 IEEE/ACM International Workshop on Cloud Intelligence (Cloud- Intelligence). IEEE, 2021, pp. 31–36

    2021

  65. [73]

    Robust failure diagnosis of microservice system through multimodal data,

    S. Zhang, P. Jin, Z. Lin, Y . Sun, B. Zhang, S. Xia, Z. Li, Z. Zhong, M. Ma, W. Jinet al., “Robust failure diagnosis of microservice system through multimodal data,”IEEE Transactions on Services Computing, no. 01, pp. 1–14, 2023

    2023

  66. [74]

    Eadro: An end-to-end troubleshooting framework for microservices on multi-source data,

    C. Lee, T. Yang, Z. Chen, Y . Su, and M. R. Lyu, “Eadro: An end-to-end troubleshooting framework for microservices on multi-source data,” in Proceedings of ICSE. IEEE, 2023, pp. 1750–1762

    2023

  67. [75]

    Diagnosing performance issues in microservices with heterogeneous data source,

    C. Hou, T. Jia, Y . Wu, Y . Li, and J. Han, “Diagnosing performance issues in microservices with heterogeneous data source,” inProceedings of ISPA/BDCloud/SocialCom/SustainCom. IEEE, 2021, pp. 493–500

    2021

  68. [76]

    Recommending root-cause and mitigation steps for cloud incidents using large language models,

    T. Ahmed, S. Ghosh, C. Bansal, T. Zimmermann, X. Zhang, and S. Rajmohan, “Recommending root-cause and mitigation steps for cloud incidents using large language models,” inProceedings of ICSE. IEEE, 2023, pp. 1737–1749

    2023

  69. [77]

    L4: Diagnosing large-scale llm training failures via automated log analysis,

    Z. Jiang, J. Huang, G. Yu, Z. Chen, Y . Li, R. Zhong, C. Feng, Y . Yang, Z. Yang, and M. Lyu, “L4: Diagnosing large-scale llm training failures via automated log analysis,” inProceedings of FSE, 2025, pp. 51–63

    2025

Pith tools

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