[Paper] 用大锤敲开螺母？重新审视自动化编译器故障隔离

发布: 1周前 (2025年12月18日 GMT+8 17:22)

7 min read

原文: arXiv

看起来您只提供了来源链接，但没有贴出需要翻译的正文内容。请把要翻译的文本（例如摘要、章节或其他段落）粘贴在这里，我会按照要求保留链接并进行简体中文翻译。

Overview

编译器是将源代码转换为可运行程序的无形主力军，因此编译器中的一个错误可能会导致整个工具链崩溃。本文将开发者已经在使用的日常“查看提交历史”方法，与一套复杂的基于光谱的故障定位（SBFL）技术进行对比，探讨哪种方法能够更快帮助你找到有问题的更改。

Empirical head‑to‑head comparison of a simple BIC‑based strategy (named Basic) with several state‑of‑the‑art SBFL methods on a large benchmark (60 GCC + 60 LLVM bugs). → 实证的正面对比 简单的基于 BIC 的策略（命名为 Basic）与多种最先进的 SBFL 方法，在大型基准（60 个 GCC + 60 个 LLVM bug）上的比较。
Demonstration that Basic is competitive and often superior on Top‑1 and Top‑5 ranking metrics, challenging the assumption that complex SBFL always wins. → 展示 Basic 具有竞争力，并且在 Top‑1 和 Top‑5 排名指标上常常更优，挑战了复杂 SBFL 总是胜出的假设。
Recommendation of Basic as a baseline for future compiler‑fault‑isolation research, providing a low‑overhead, reproducible reference point. → 建议将 Basic 作为基准 用于未来的编译器故障定位研究，提供低开销、可复现的参考点。
Open‑source benchmark and tooling (scripts for binary‑search commit isolation and SBFL pipelines) released to the community for repeatable experiments. → 开源基准和工具（用于二分搜索提交隔离和 SBFL 流水线的脚本）已向社区发布，以便进行可重复的实验。

Bug 选择 – 作者挑选了 120 个真实的编译器 bug（GCC 60 个，LLVM 60 个），这些 bug 都有公开的测试用例和版本历史。
基本策略 –
- 确定最新的 good 版本（测试通过）和最早的 bad 版本（测试失败）。
- 在提交时间线上进行二分搜索，以定位 引入 bug 的提交 (BIC)。
- 将该提交中涉及的每个文件标记为潜在的故障位置。
SBFL 技术 – 实现了几种流行的 SBFL 算法（如 Ochiai、Tarantula、DStar），它们利用测试执行光谱（通过/失败）对源文件进行排序。
评估指标 – 测量真实故障文件在每种技术排序列表中出现于前 1、前 5、前 10 位的频率。
统计分析 – 使用 Wilcoxon 符号秩检验和效应量计算来评估差异的显著性。

更快的调试周期 – 团队可以将二分搜索 BIC 方法作为首选工具，与耗尽式 SBFL 运行相比，大幅减少构建次数。
降低基础设施成本 – 无需繁重的插桩或测试覆盖率收集；只需一个标记好/坏发布的简单 CI 流水线即可。
与现有工作流的集成 – 大多数版本控制系统已经支持 bisect 命令；本文实际上将该实践形式化，用于编译器错误。
工作重点的优先级 – 当 Basic 标记出一小组文件（通常只有一两个）时，开发者可以将代码审查和静态分析资源集中在这些文件上，将 SBFL 留给提交历史噪声较大的“难点”案例。
工具链 – 已发布的脚本可以直接嵌入 GCC/LLVM 项目的 CI 流水线，或适配到任何拥有可复现测试套件的语言编译器。