Where did we fail? -- Reproducing build failures in embedded open source software
本文介绍了 PhantomRun，这是一个统一的抽象层和数据集，旨在标准化嵌入式开源软件持续集成构建日志与元数据的检索及忠实复现，从而支持对历史构建失败进行高重构精度的大规模可复现研究。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象你是一名侦探，正在调查去年一家工厂发生的神秘事件。这家工厂生产复杂的 gadget（嵌入式软件），将硬件与代码结合在一起。每当测试新的 gadget 设计时，工厂就会运行一条庞大、自动化的装配线（持续集成，简称 CI）。有时，装配线会断裂，机器带着错误信息停止运行。
问题出在哪里？工厂一片混乱。它针对每一次测试都使用不同的工具、不同的机器人和不同的蓝图。当测试失败时，机器会打印出一张冗长、杂乱的收据（构建日志），解释为何失败。但关键在于：这些收据在几天后就会被丢弃，而打印它们的具体机器人甚至可能已不复存在。如果你想研究六个月前机器为何损坏，你无法仅仅查看收据；你必须尝试重建完全相同的工厂设置，看看它是否会再次损坏。
这正是论文《我们究竟在哪里失败了？》所解决的问题。作者们构建了一个名为PhantomRun的工具来解决这一问题。
问题：幽灵工厂
在嵌入式软件的世界中（例如你汽车、恒温器或医疗设备内部的代码），构建软件就像试图在一个每次你走进来布局都会改变的厨房里烤蛋糕。
- 食材在变：工具（编译器）和部件（依赖项）不断更新。
- 厨房在变：工厂针对每次测试使用不同的机器人（运行器）和蓝图（配置）。
- 证据消失：当测试失败时，错误日志就像一张一周后就会被粉碎的收据。
因此，如果开发者想要研究过去的失败以了解如何修复它，他们往往无法做到。他们需要重造的“厨房”已不复存在。
解决方案：PhantomRun（“时间旅行”蓝图）
作者们创建了PhantomRun，它就像是为这些混乱工厂提供的一种神奇、标准化的蓝图。PhantomRun 不是试图寻找原本杂乱的机器人，而是构建一个完美的、隔离的“时间胶囊”（容器），以模拟原始失败的确切条件。
可以这样理解：
- 原始场景：你试图复刻一家已倒闭餐厅的特定菜肴，但你不知道他们使用的确切面粉品牌或烤箱温度。你只能猜测，结果菜肴的味道截然不同。
- PhantomRun 场景：PhantomRun 是一台机器，它扫描旧餐厅的点餐单，找出确切的面粉品牌和烤箱温度，并在你的地下室里搭建一个临时的、完美的厨房复制品。然后它再次烹饪这道菜，看看它是否以完全相同的方式失败。
他们做了什么
团队将这个工具应用于四个主要的开源硬件项目（例如Zephyr和RTEMS，它们是智能设备的操作系统）。他们研究了过去超过4,600 次失败的测试。
他们提出了两个主要问题：
- 我们能重建工厂吗？（我们能重现失败吗？）
- 它是否以相同的方式损坏？（新失败是否与旧失败完全相同？）
结果
结果出乎意料地成功：
- 91.8% 的成功率：他们成功地为近 92% 的失败重建了“时间胶囊”工厂并再次运行了测试。
- 98% 的准确率：当他们成功重现时，结果几乎总是相同的。如果原始测试失败，新的测试也会失败。如果原始测试成功，新的测试也会成功。
- “噪音”因素：唯一的差异是微小且无害的，例如日志上的时间戳，或两个无关步骤发生的顺序。核心的“错误信息”（蛋糕烧焦的原因）是完全相同的。
为何部分失败
少数他们无法重现失败的情况（约占 8%），并非因为他们的工具不好。而是因为“食材”永远消失了。
- 硬件缺失：某些测试需要特定的物理芯片或电路板，而这些已不复存在。
- 工具丢失：某些用于构建代码的软件工具已从互联网上删除，或更新到如此程度以至于变得不兼容。
- 秘密配方：某些项目使用了研究人员无法访问的私有专有工具。
核心结论
该论文得出结论，我们可以将这些转瞬即逝、杂乱的错误日志转化为永久、可靠的研究工具。通过使用 PhantomRun，开发者和研究人员现在可以回顾历史失败，在受控环境中研究它们，并从中吸取教训，而无需依赖原本混乱的工厂设置。
简而言之：PhantomRun 将“哎呀，日志没了”转变为“让我们重建它损坏的确切时刻并加以研究”。 这有助于我们理解智能设备为何失败，以及如何在未来使其更加可靠。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。