How Often Do Single-Statement Bugs Occur? The ManySStuBs4J Dataset
程序修复是软件工程中的一个重要而又困难的问题。实现可接受性能的一种方法是关注简单bug的类，例如具有单个语句修复的bug，或者匹配一小组bug模板的bug。然而，很难估计简单错误的修复技术的召回率，因为没有关于相关错误在代码中发生频率的数据集。为了填补这一空白，我们提供了一个数据集，其中包含从1,000个流行的开源Java项目中挖掘出来的153,652个单语句错误修复更改，并通过它们是否匹配16个错误模板中的任何一个进行了注释，这些模板的灵感来自最先进的程序修复技术。在最初的分析中，我们发现大约33%的简单错误修复与模板匹配，这表明相当数量的单语句错误可以用相对较小的模板集修复。此外，我们发现模板拟合错误的出现频率约为每1，600 - 2，500行代码中出现一个错误（以项目最新版本的大小衡量）。我们希望该数据集将证明为未来的工作在程序修复和经验软件工程的研究资源。
2020-04-10 cs.PL cs.SE
A Comprehensive Study of Bug Fixes in Quantum Programs
随着量子编程的发展，越来越多的量子编程语言正在开发中。因此，调试和测试量子程序变得越来越重要。虽然经典程序中的错误修复已经走过了很长的路，但在量子程序中缺乏研究。为此，本文提出了一个全面的研究量子程序中的错误修复。我们收集和调查了来自四种流行的量子编程语言Qiskit，Cirq，Q#和ProjectQ的96个真实世界的错误及其修复。我们的研究表明，量子程序中的错误有很大比例是量子特定的错误（超过80%），这需要在错误修复领域进行进一步的研究。我们还总结和扩展了量子程序中的错误模式，并对最关键的部分--数学相关错误进行了细分，使其更适用于量子程序的研究。我们的研究结果总结了量子程序中缺陷的特征，为研究量子程序的测试和调试提供了基础。
2022-01-21 cs.PL cs.SE quant-ph
A new perspective on the competent programmer hypothesis through the reproduction of bugs with repeated mutations
本研究通过变异链复现真实缺陷，检验胜任程序员假说，发现该假说成立但变异测试缺少关键算子。
2023-05-16 cs.SE
Human Attention During Localization of Memory Bugs in C Programs
University of Notre Dame（圣母大学）；Vanderbilt University（范德堡大学）
研究人类在 C 程序中定位内存错误时的视觉注意力，招募 21 名程序员在三个程序中定位内存错误，收集 31 小时观察数据，分析成功率等任务结果、总体视觉注意力模式及成败案例中视觉注意力模式差异。
2026-07-20 cs.SE
Finding Compiler Bugs through Cross-Language Code Generator and Differential Testing
提出CrossLangFuzzer框架，利用通用IR和三种变异技术自动生成跨语言测试程序，通过差分测试发现多个JVM语言编译器缺陷，其中TypeChanger最有效，共发现24个已确认缺陷。
2025-07-09 cs.PL cs.SE
Leveraging Data Characteristics for Bug Localization in Deep Learning Programs
针对深度学习程序结构性缺陷难定位的问题，提出Theia，结合训练数据集特征在训练初期检测Keras/PyTorch程序缺陷并给出位置与修复建议，在40个真实程序上定位57/75个缺陷，显著优于NeuraLint的17/75。
2024-12-08 cs.SE
Empirical Review of Java Program Repair Tools: A Large-Scale Experiment on 2,141 Bugs and 23,551 Repair Attempts
在过去的十年中，基于测试套件的自动程序修复的研究有了显着增长。每年，新的方法和实现都会出现在主要的软件工程场所。然而，大多数这些方法都是在单一的bug基准上进行评估的，其他研究人员也很少复制这些bug。在本文中，我们提出了一个大规模的实验，使用11个Java测试套件为基础的修复工具和5个基准的错误。我们的目标是更好地了解自动程序修复工具在大量基准测试中的现状。我们的调查是指导的假设，修复工具的可修复性可能不会在不同的基准程序错误的一般化。我们发现，这11个工具1）能够为5个基准测试中21%的bug生成补丁，2）与其他基准测试相比，在Defects 4J上具有更好的性能，通过为Defects 4J中47%的bug生成补丁，而其他基准测试中的bug只有10-30%。我们的实验总共包括23，551次修复尝试，我们用来找到非补丁生成的原因。本文对这些原因进行了分析，有助于维修工具设计人员改进技术和工具。
2019-05-28 cs.SE
Characterizing Real-World Bugs in Tile Programs for Automated Bug Detection
University of Texas at Dallas（达拉斯大学）；Institute of Systems for Advanced Computing, Fudan University（复旦大学高级计算系统研究所）；Beijing Tongming Lake Information Technology Application Innovation Center（北京通明湖信息技术应用创新中心）；Shanghai Institute of Systems for Open Computing（上海开放计算系统研究所）；Key Lab of HCST (PKU), MOE（北京大学计算机辅助设计与图形学教育部重点实验室；计算机科学系，北京大学）；SCS, Peking University
本文首次系统研究了Tile程序代码生成中的Bug，通过收集401个GitHubbug报告，识别出301个Tile程序代码生成Bug，分析其根本原因、症状、输入模式、触发测试或acles以及修复策略，为构建针对Tile编译器基础设施的调试、测试和修复工具提供基础见解。
2026-07-30 cs.SE
Applying CodeBERT for Automated Program Repair of Java Simple Bugs
软件调试和程序修复是软件工程中最耗时和劳动密集型的任务之一，自动化将使其受益匪浅。在本文中，我们提出了一种基于CodeBERT的新型自动程序修复方法，CodeBERT是一种基于变换器的神经架构，在大型源代码语料库上进行了预训练。我们在ManySStuBs 4J小型和大型数据集上微调我们的模型，以自动生成修复代码。结果表明，我们的技术在19-72%的情况下准确地预测了开发人员实现的固定代码，具体取决于数据集的类型，每个错误不到一秒。我们还观察到，我们的方法可以生成不同长度的修复（短和长），并可以修复不同类型的错误，即使在训练数据集中只存在这些类型的错误的几个实例。
2021-03-30 cs.SE
Automatically finding atomic regions for fixing bugs in Concurrent programs
本文提出了一种技术，用于自动构建一个修复错误的并发程序：给定一个并发程序，不满足用户提供的断言，我们推断原子块修复程序。原子块保护一段代码，并确保它在不受其他线程中断的情况下运行。我们的技术使用一个验证工具作为一个子程序，以找到最小的原子区域，消除所有的错误在一个给定的程序。保持原子区域较小可以实现最大的并发性。我们已经在一个名为AtomicInf的工具中实现了我们的方法。AtomicInf的用户可以为推断的修复在强和弱原子性语义之间进行选择。虽然前者更容易找到，但后者提供了有关修复的错误的更多信息。我们在几个基准测试中运行了AtomicInf，并在所有基准测试中找到了最小和最精确的原子区域。我们在我们的设置中实现了一种早期的技术，并观察到AtomicInf的平均速度是早期方法的1.7倍。
2014-03-07 cs.SE
Compiler Testing With Relaxed Memory Models
针对现有并发编译器测试技术无法兼顾边界内漏洞覆盖与大规模程序可扩展性的问题，提出工业级测试工具Téléchat，通过对比源与架构内存模型下的程序行为发现漏洞，性能优于现有技术且已部署应用。
2024-01-29 cs.AR cs.PL cs.SE
UBfuzz: Finding Bugs in Sanitizer Implementations
本文提出测试框架 UBfuzz，通过生成含未定义行为的程序并利用 crash-site mapping 测试预言机进行差分测试，在 GCC 和 LLVM sanitizers 中发现 31 个 bug，揭示了 sanitizer 的假阴性问题。
2024-01-09 cs.CR cs.PL cs.SE
Characterizing Bugs in Python and R Data Analytics Programs
该研究通过分析Stack Overflow帖子、GitHub修复提交与Issue，系统对比了R和Python数据分析程序的Bug类型、根本原因及关联，得出多维度差异结论并贡献了人工验证的Bug数据集。
2023-06-14 cs.SE
What we can learn from how programmers debug their code
研究人员已经开发了许多调试方法来帮助程序员在调试过程中，但这些方法很少在实践中使用。在本文中，我们将探讨程序员如何调试他们的代码，以及研究人员在开发调试方法时应该考虑什么。我们进行了一个在线问卷调查，102名程序员提供了最近修复的错误的信息。我们发现大多数bug（69.6%）是语义bug.内存和并发性bug不那么频繁地发生（6.9%和8.8%），但它们消耗更多的调试时间。定位一个bug比复制和修复它更困难，程序员通常只使用IDE内置的工具进行调试。此外，程序员在调试时经常使用复制-观察-演绎模式。这些结果表明，调试支持是特别有价值的内存和并发错误。此外，研究人员应该专注于故障定位阶段，并将他们的工具集成到常用的IDE中。
2021-03-23 cs.SE
Gradient-Based Program Repair: Fixing Bugs in Continuous Program Spaces
KTH Royal Institute of Technology（皇家理工学院）
本文提出基于梯度的程序修复方法，通过在可微数值程序空间中进行连续优化，有效修复符号程序中的错误，首次将程序修复视为数值空间中的连续优化问题。
2026-03-25 cs.LG cs.PL cs.SE
Bug Characteristics in Quantum Software Ecosystem
随着近年来量子计算的发展，量子软件对于探索量子计算系统的全部潜力至关重要。量子编程不同于经典编程，例如，量子程序的状态本质上是概率性的，并且由于量子机制的不稳定性，量子计算机容易出错。因此，量子软件项目中的bug的特征可能与经典软件项目中的bug有很大不同。这项工作旨在了解量子软件项目中错误的特征，以便提供见解，帮助设计有效的测试和调试机制。为了实现这一目标，我们对125个量子软件项目的错误报告进行了实证研究。我们观察到量子软件项目比经典软件项目更容易出错，并且量子项目的错误比经典项目的错误修复成本更高。我们还确定了错误的类型和它们发生的量子编程组件。我们的研究表明，错误分布在不同的组件中，但量子特定的错误特别出现在编译器，门操作和状态准备组件中。最常见的三种错误类型是程序异常错误、配置错误和数据类型和结构错误。我们的研究强调了量子软件开发中一些特别具有挑战性的领域，例如缺乏科学的量子计算库来实现量子计算的综合数学函数。量子开发人员还寻求专门的量子软件工程数据操作库，如量子计算的Numpy。我们的研究结果还为未来的工作提供了见解，以推进量子软件的量子程序开发，测试和调试，例如为调试低级电路提供工具支持。
2022-04-25 cs.SE
An Annotation-based Approach for Finding Bugs in Neural Network Programs
针对神经网络程序缺乏输入约束导致自动测试易生成无效输入的问题，本文提出 aNNoTest，利用专用注解和基于属性的测试生成有效随机输入，并在19个程序中发现94个缺陷。
2023-01-24 cs.SE
BugsInPy: A Database of Existing Bugs in Python Programs to Enable Controlled Testing and Debugging Studies
受Java缺陷基准Defects4J启发，本研究构建了包含17个真实Python项目493个真实缺陷的BugsInPy基准数据库及工具，以填补Python测试调试基准的不足，推动相关工具研究发展。
2024-01-27 cs.SE
ReduKtor: How We Stopped Worrying About Bugs in Kotlin Compiler
众所周知，缺陷定位是软件工程中的一个难题，特别是在编译器开发中，将输入程序减少到最小的复制示例是有益的;这种技术通常称为delta调试。另一个问题是，每种新的程序设计语言都有自己独特的怪癖和弱点，这使得完全有效地重用现有的工具和方法几乎是不可能的。在这篇经验论文中，我们解决了delta调试问题w.r.t. Kotlin，一种来自JetBrains的相对较新的程序设计语言。我们的方法是基于程序切片，分层增量调试和Kotlin特定转换的新组合，它们相互协同。我们在一个名为ReduKtor的原型中实现了它，并对合成和真实的Kotlin程序进行了广泛的评估;我们还将其性能与经典的delta调试技术进行了比较。评估结果支持我们的Kotlin delta调试方法的实际可用性，也表明了使用语言无关和语言特定技术来实现最佳还原效率和性能的重要性。
2019-09-16 cs.PL cs.SE
Critical Review of BugSwarm for Fault Localization and Program Repair
基准测试在评估解决方案的效率和有效性以自动化软件开发生命周期的几个阶段方面发挥着重要作用。此外，如果设计得好，它们也可以作为一个重要的人工制品来比较不同的方法。BugSwarm是最近发布的一个基准测试，其中包含3，091对失败和通过的持续集成构建。根据作者的说法，基准测试的设计考虑到了自动程序修复和故障定位社区。鉴于针对这些社区的基准应该具有几个特征（例如，一个错误的声明需要存在），我们已经剖析了基准，以充分了解基准是否适合这些社区。我们的批判性分析发现，在基准测试中有几个限制：只有112/3，091（3.6%）适合评估自动故障定位或程序修复技术。
2019-05-22 cs.SE
CMind: An AI Agent for Localizing C Memory Bugs
University of Notre Dame（圣母大学）
CMind通过模拟人类程序员行为，利用大语言模型和引导决策方法，定位C程序中的内存错误。
2026-02-20 cs.SE
MPISE: Symbolic Execution of MPI Programs
消息传递接口（MPI）在并行计算中起着重要的作用。许多并行应用程序都是以MPI程序的形式实现的。现有的MPI程序缺陷检测方法在提供输入和非确定性覆盖方面存在不足，导致缺陷漏诊。在本文中，我们采用符号执行，以确保输入的覆盖率，并提出了一个飞行调度算法，以减少交错探索的非确定性覆盖，同时确保健全性和完整性。我们已经实现了我们的方法作为一个工具，称为MPISE，它可以自动检测MPI程序中的死锁和运行时错误。在基准程序和真实MPI程序上的实验结果表明，MPISE能够有效地发现程序中的错误。此外，我们的工具还提供了诊断信息和重放机制，以帮助理解错误。
2014-09-15 cs.DC cs.PL cs.SE
PanicFI: An Infrastructure for Fixing Panic Bugs in Real-World Rust Programs
针对Rust程序panic缺陷修复难的问题，提出PanicFI基础设施，构建含102个真实缺陷的Panic4R数据集，挖掘Rust特有修复模式，开发首款自动化修复工具PanicKiller，已修复28个开源缺陷，验证了模式有效性。
2024-11-04 cs.SE
The Output-Space Hypothesis: Enumerative Equivalence Checking for Tensor Programs
University of Pennsylvania（宾夕法尼亚大学）
提出输出空间假设，通过翻转量词检查单个输出位置对所有输入的等价性，实现张量程序更一致的错误发现，在6988个AI编写的CUDA内核中找出600个隐藏错误。
2026-09-18 cs.LG cs.PL cs.SE
Nopol: Automatic Repair of Conditional Statement Bugs in Java Programs
我们提出了NOPOL，一种自动修复错误条件语句的方法（即，if-then-else语句）。这种方法将一个有缺陷的程序和一个测试套件作为输入，并生成一个带有条件表达式的补丁作为输出。测试套件需要包含通过测试用例，以模拟程序的预期行为，以及至少一个失败的测试用例，以揭示要修复的错误。NOPOL的过程包括三个主要阶段。首先，NOPOL采用天使修复本地化，以确定在测试执行过程中的条件的预期值。其次，运行时跟踪收集用于收集变量及其实际值，包括原始数据类型和面向对象的特征（例如，空性检查），以用作补丁生成的构建块。第三，NOPOL将这些收集的数据编码成可满足性模理论（SMT）问题的实例，然后将SMT实例的可行解翻译回代码补丁。我们评估NOPOL的22个真实世界的错误（16个错误与错误的IF条件和6个错误与缺少先决条件）在两个大型开源项目，即Apache Commons Math和Apache Commons Lang。这些错误的实证分析表明，我们的方法可以有效地修复错误的IF条件和缺少先决条件。我们说明了NOPOL的能力和局限性，使用真正的错误修复的案例研究。
2018-11-10 cs.SE
Petri Nets-based Methods on Automatically Detecting for Concurrency Bugs in Rust Programs
本文提出一种基于Petri网的Rust并发缺陷检测方法，通过语法保持的程序转换、上下文感知状态压缩和可达性分析，结合流敏感指针分析，在基准测试中显著降低了误报和漏报，并实现了比动态工具Miri更快的验证速度。
2025-09-23 cs.FL cs.PL cs.SE
Multi-Location Program Repair Strategies Learned from Past Successful Experience
自动程序修复（Automated program repair，APR）在减少软件维护工作量和时间消耗方面具有巨大的潜力，近年来成为软件工程的研究热点，提出了许多方法。多位置程序修复由于其逻辑和结构的复杂性一直是该领域的一个挑战。虽然一些方法并不声称具有解决多位置错误的功能，但它们在实践中为这些缺陷生成正确的补丁。在本文中，我们首先对Defects4J中的多位置错误进行了观察，并将其分为两类（即，相似的和相关的多位置错误）基于其补丁中的修复动作。然后，我们总结了当前工具修复Defects4J中多位置错误的情况。我们分析了当前工具生成的22个补丁，并提出了两个可行的策略来修复多位置错误，通过两个详细的案例研究来说明它们。最后，通过修复两个从未修复过的漏洞，验证了该方法的可行性。通过借鉴以往的成功经验，指出了多位置程序修复的可能途径。
2019-01-07 cs.SE
Mining Bug Repositories for Multi-Fault Programs
针对 Defects4J 与 BugsInPy 多为单缺陷条目的局限，本文利用测试用例移植和故障位置转换构建保留原数据集特性的真实多故障程序数据集。
2024-04-10 cs.SE
DEAR: A Novel Deep Learning-based Approach for Automated Program Repair
现有的基于深度学习（DL）的自动程序修复（APR）模型在修复一般软件缺陷方面受到限制。我们提出了{ \tool }，这是一种基于DL的方法，支持修复一般错误，这些错误需要立即对一个或多个代码块中的一个或多个连续语句进行相关更改。我们首先设计了一种新的故障定位（FL）技术，用于多块、多语句修复，该技术将传统的基于频谱（SB）的FL与深度学习和数据流分析相结合。它接受SBFL模型返回的错误语句，检测出要立即修复的错误块，并扩展块中的错误语句$s$，以包括$s$周围的其他可疑语句。我们设计了一个基于树的两层LSTM模型，该模型结合了循环训练，并使用分治策略来学习适当的代码转换，以便在由周围子树组成的适当固定上下文中固定多个语句。我们在三个数据集上进行了几次实验来评估{ \tool }：Defects 4J（395个错误）、BigFix（+26k个错误）和CPatMiner（+44k个错误）。在Defects 4J数据集上，{ \tool }在仅使用前1个修补程序自动修复的错误数量方面优于基线，从42\%到683\ %。在BigFix数据集上，它比现有的基于DL的APR模型多修复了31- 145个错误。在CPatMiner数据集中，在667个修复的bug中，有169个（25.3%）多块/多语句bug。与最先进的基于DL的APR模型相比，{ \tool }分别多修复了71个和164个错误，其…
2022-05-04 cs.SE
Hints Help Finding and Fixing Bugs Differently in Python and Text-based Program Representations
本研究通过753人众包实验发现，提示类型和程序表示（Python与文本）显著影响用户发现和修复错误的准确性，文本表示更有利，提示效果因用户理解而异，为个性化编程工具设计提供启示。
2024-12-17 cs.SE
Towards Runtime Verification of Programmable Switches
TU Berlin（柏林工业大学）；SAP（SAP公司）；Swisscom（瑞士电信）；University of Vienna（维也纳大学）；Huawei（华为）；MPI-Informatics（马克斯·普朗克信息学研究所）；Saarland University（萨尔大学）
有没有可能在没有人类参与的情况下修补P4程序中的软件错误？我们表明，这是部分可能的，在许多情况下，由于在软件测试和P4程序的结构的进步。我们的见解是，运行时验证可以检测错误，即使是那些在编译时没有检测到的错误，与机器学习指导的模糊。这使得使用像Tarantula这样的软件测试技术能够更加自动化和实时地定位P4程序中的错误。一旦P4程序中的错误被定位，由于P4的可编程特性，错误代码可以被修补。此外，还可以检测到与平台相关的bug。从P4_14到P4_16（最新版本），我们观察到随着可编程块的增加，P4程序的可修补性相应增加。为此，我们设计，开发和评估P6，（a）检测，（b）本地化，（c）补丁错误P4程序与最小的人类互动。P6非侵入性地测试P4开关，即，不需要修改P4程序来检测和定位错误。我们使用P6原型来检测和修补部署在两个不同交换机平台上的8个公开的P4应用程序中的7个现有错误：行为模型（bmv2）和Tofino。我们的评估表明，P6显着优于错误检测基线，同时在P4程序（如switch.p4）中生成更少的数据包和补丁错误，而不会触发任何回归。
2020-04-26 cs.LG cs.NI cs.SE
LLM-Powered Test Case Generation for Detecting Bugs in Plausible Programs
Peking University（北京大学）；Nanyang Technological University（南洋理工大学）；King’s College London（伦敦国王学院）；University College London（伦敦大学学院）；National Key Laboratory of Data Space Technology and System（数据空间技术与系统国家重点实验室）
针对似是而非程序中棘手Bug的检测难题，提出基于LLM的三阶段方法TrickCatcher，通过生成程序变体和测试输入并比较输出不一致性来发现Bug，在召回率、精确率和F1分数上分别达到SOTA基线的1.80倍、2.65倍和1.66倍。
2025-05-31 cs.LG cs.SE
Attention Please: Consider Mockito when Evaluating Newly Proposed Automated Program Repair Techniques
自动程序修复（Automated program repair，APR）技术近年来引起了广泛的关注。与此同时，许多基准测试已经建立了评估APR技术的性能，其中Defects 4J是使用最广泛的基准测试之一。然而，在Mockito，一个项目中的缺陷增强后的版本的Defects 4J，没有得到太多的关注，最近的研究。在本文中，我们的目的是调查评估APR技术时考虑Mockito错误的必要性。我们的研究结果表明：1）与其他项目的bug相比，Mockito bug的修复并不复杂; 2）与修复Mockito bug所需的模式相比，最先进的工具修复的bug共享相同的修复模式;但是，在此情况下，3）最先进的工具在Mockito错误上表现不佳（Nopol只能正确修复一个bug，而SimFix和CapGen无法修复Mockito中的任何bug，即使所有bug位置都已暴露）。从这些结果中，我们得出结论，现有的APR技术可能是过拟合的评估科目，我们应该考虑Mockito，甚至更多的错误，从其他项目，当评估新提出的APR技术。我们进一步找出了一个独特的修复行动所需的修复Mockito错误命名为外部包添加。从与源代码相关联的测试代码中恢复外部包对于扩大搜索空间是可行的，并且该动作可以用现有的修复动作来增强以推进现有技术。
2019-01-08 cs.SE
Towards More Reliable Automated Program Repair by Integrating Static Analysis Techniques
自动程序修复的一个长期存在的公开挑战是过拟合问题，这是由于没有足够或不完整的规范来验证生成的补丁是否正确而引起的。大多数可用的修复系统依赖于弱规范（即，从测试用例合成的规范），这限制了生成的修复的质量。为了加强规范和提高修复的质量，我们建议更紧密地结合静态错误检测技术与自动程序修复。该集成将自动程序修复与静态分析技术相结合，使得错误检测模式可以合成为修复系统可以使用的规范。我们探索这种集成使用两种类型的错误的可行性：算术错误，如整数溢出，和逻辑错误，如终止错误。作为我们分析的一部分，我们提出了一些意见，有助于提高这些类别的错误补丁生成。此外，这些观察有助于缩小候选块搜索空间，并推断有效的搜索顺序。
2021-11-10 cs.SE
Isolating Compiler Bugs by Generating Effective Witness Programs with Large Language Models
针对编译器缺陷隔离中测试程序变异低效的问题，提出 LLM4CBI，通过复杂度引导提示、强化学习提示选择和反馈验证生成有效见证程序，在 GCC/LLVM 真实缺陷上显著优于 DiWi 与 RecBi。
2024-05-08 cs.SE
Automated Conformance Testing for JavaScript Engines via Deep Compiler Fuzzing
JavaScript（JS）是一种流行的、与平台无关的程序设计语言。为了确保JS程序在不同平台上的互操作性，JS引擎的实现应该符合ECMAScript标准。然而，这样做是具有挑战性的，因为API行为有许多微妙的定义，并且定义不断发展。我们提出了COMFORT，一个新的编译器模糊框架，用于检测JS引擎的错误和行为偏离ECMAScript标准。COMFORT利用基于深度学习的语言模型的最新进展，自动生成JS测试代码。与以前的模糊器不同，COMFORT利用结构良好的ECMAScript规范自动生成测试数据以及测试程序，以暴露开发人员或手动编写的测试用例可能忽略的错误。然后，COMFORT在生成的测试用例上应用差异测试方法，以暴露标准一致性错误。我们将COMFORT应用于十个主流JS引擎。在200小时的自动化并发测试运行中，我们发现了所有测试过的JS引擎中的错误。我们已经确定了158个独特的JS引擎错误，其中129个已经得到验证，115个已经被开发人员修复。此外，21个Comfort生成的测试用例已添加到Test262，官方ECMAScript一致性测试套件。
2021-04-15 cs.PL cs.SE
Bugs in Machine Learning-based Systems: A Faultload Benchmark
Polytechnique Montréal（蒙特利尔综合理工学院）；York University（约克大学）
随着机器学习（ML）在各个领域的应用迅速升级，ML组件的质量越来越受到关注。然后，技术和工具的增长旨在提高ML组件的质量并将其安全地集成到基于ML的系统中。虽然这些工具大多使用bug的生命周期，但没有标准的bug基准来评估它们的性能，比较它们并讨论它们的优点和缺点。在这项研究中，我们首先调查的可重复性和可验证性的错误在ML为基础的系统，并显示在每一个最重要的因素。然后，我们探讨了在基于ML的软件系统中生成bug基准的挑战，并提供了一个bug基准，即defect4ML，满足标准基准的所有标准，即相关性，再现性，公平性，可验证性和可用性。这个faultload基准测试包含了GitHub和Stack Overflow中ML开发人员报告的100个bug，使用了两个最流行的ML框架：TensorFlow和Keras。defect4ML还解决了基于ML的软件系统的软件可靠性工程中的重要挑战，例如：1）框架的快速变化，通过为不同版本的框架提供各种错误，2）代码可移植性，通过在不同的ML框架中提供类似的错误，3）错误可再现性，通过提供完全可再现的错误以及关于所需依赖关系和数据的完整信息，以及4）缺乏关于错误的详细信息，通过提供错误来源的链接。基于ML的系统从业者和研究人员可能会对defect4ML感兴趣，以评估他们的测试工具和技术。
2023-01-16 cs.LG cs.SE
GitBug-Java: A Reproducible Benchmark of Recent Java Bugs
针对现有漏洞修复基准数据集缺乏近期案例与可复现性的问题，研究提出包含199个2023年Java漏洞的可复现基准GitBug-Java，为APR与FL研究提供更贴合当前实践的评估基础。
2024-02-06 cs.SE
Silent Bugs in Deep Learning Frameworks: An Empirical Study of Keras and TensorFlow
Polytechnique Montreal（蒙特利尔理工学院）
本研究首次实证调查Keras与TensorFlow中的静默缺陷，通过分析1168个问题识别出77个可复现缺陷，分类并评估其影响，提出防护指南。
2023-09-01 cs.LG cs.SE
Bears: An Extensible Java Bug Benchmark for Automatic Program Repair Studies
错误基准测试对于经验性地评估自动程序修复工具是必不可少的。在本文中，我们提出了熊，一个项目收集和存储错误到一个可扩展的错误基准自动修复研究在Java中。bug的收集依赖于持续集成（CI）的提交构建状态，以从GitHub上托管的开源项目中找到潜在的bug和补丁程序版本对。每一对程序版本都通过一个管道，在管道中尝试复制一个错误及其补丁。再现流水线的核心步骤是在两个程序版本上执行程序的测试套件。如果在有缺陷的程序版本候选中发现测试失败，并且在其修补程序版本候选中没有发现测试失败，则错误及其修补程序成功再现。Bears的独特之处在于使用CI（构建）来识别有缺陷和打补丁的程序版本候选者，这在过去几年中已被广泛采用在开源项目中。这种方法允许我们从各种各样的项目中收集bug，而不仅仅是使用bug跟踪系统的成熟项目。此外，Bears被设计为公开可用，并通过在给定的GitHub存储库中自动创建带有bug的分支来轻松扩展研究社区，这些分支可用于Bears存储库中的拉取请求。我们在本文中介绍的方法所采用的熊，我们提供了版本1.0的熊，其中包含251个可重复的错误收集72个项目，使用特拉维斯CI和Maven构建环境。
2019-01-17 cs.SE
Chasing Elusive Memory Bugs in GPU Programs
Indian Institute of Science（印度科学学院）
SCuBA通过分析CPU和GPU代码中的语义关系，首次提出编译时检测GPU程序中隐蔽内存错误的方法，有效识别越界访问问题。
2026-01-29 cs.SE
Symbolic Partial-Order Execution for Testing Multi-Threaded Programs
我们描述了一种多线程程序的系统测试技术。我们结合准最优偏序约简，一个国家的最先进的技术，解决路径爆炸，由于交错的非确定性，与符号执行来处理数据的非确定性。我们的技术迭代地和详尽地发现程序的所有执行。它使用偏序表示程序执行，并使用底层展开语义查找下一次执行。我们避免了使用截止事件的冗余程序痕迹的探索。我们实现了我们的技术作为KLEE的扩展，并评估了一组大型多线程C程序。我们的实验在memcached和GNU sort中发现了几个以前未发现的bug和未定义的行为，表明新方法能够在工业规模的基准测试中发现bug。
2020-07-22 cs.PL cs.SE
MCRepair: Multi-Chunk Program Repair via Patch Optimization with Buggy Block
针对多块程序修复中依赖关系处理难、补丁空间大、候选补丁组合方法不足等问题，提出结合缺陷块、补丁优化和微调CodeBERT的MCRepair方法，在Defects4J上修复65个缺陷，性能较基线提升40%-250%。
2023-10-21 cs.SE
DESIL: Detecting Silent Bugs in MLIR Compiler Infrastructure
本文提出 DESIL，一种针对 MLIR 编译器基础设施的静默 Bug 检测方法，通过定义 UB 消除规则生成无 UB 程序、设计 lowering 路径优化策略并结合差分测试，成功检测出 23 个静默 Bug 和 19 个崩溃 Bug。
2025-04-02 cs.SE
WITCHER : Detecting Crash Consistency Bugs in Non-volatile Memory Programs
非易失性主存储器（NVM）的出现使得能够在不支付存储堆栈开销的情况下开发崩溃一致性软件。然而，在存在易失性缓存的情况下，构建正确的崩溃一致性程序仍然非常具有挑战性。本文介绍了一种用于NVM软件的崩溃一致性错误检测器WITCHER，它具有（1）可扩展性-不会遭受测试空间爆炸，（2）自动-不需要手动源代码注释，（3）精确-不会产生误报。WITCHER首先通过分析源代码和NVM访问轨迹来推断一组被认为是真正的崩溃一致性的“可能不变量”。WITCHER自动组成NVM映像，模拟那些违反可能不变量的潜在不一致（崩溃）状态。然后WITCHER通过比较有和没有模拟崩溃的程序执行的输出来执行“输出等价性检查”。它验证在测试中可能的不变违反是否是真正的崩溃一致性错误。对10个持久性数据结构、两个实际服务器和英特尔PMDK库中的5个示例代码的评估表明，WITCHER优于最先进的工具。WITCHER发现了37个（32个新的）崩溃一致性错误，这些错误都得到了确认。
2020-12-11 cs.SE
Are We Testing the Wrong Quantum Bugs? A Study of Fault Representation Gaps in Quantum Software Testing
Tulane University（杜兰大学）；The University of Texas at Dallas（德克萨斯大学达拉斯分校）；University of California, Riverside（加州大学河滨分校）
本研究对比量子突变测试工具、基准漏洞与真实量子软件漏洞，发现86.3%真实漏洞未被覆盖，指出需关注编译器等组件的故障测试，为构建更贴合实际的量子软件测试基准提供实证依据。
2026-10-19 cs.PL cs.SE
HyperPUT: Generating Synthetic Faulty Programs to Challenge Bug-Finding Tools
本文提出 HyperPUT，从种子缺陷出发通过增量程序变换自动生成可扩展规模的带缺陷 C 程序，用于多方面挑战现代缺陷发现工具并支持实证评估。
2024-02-02 cs.CR cs.SE
Hierarchical Knowledge Injection for Improving LLM-based Program Repair
Drexel University（德雷塞尔大学）；Belmont University（贝尔蒙特大学）；Florida State University（佛罗里达州立大学）
本文提出分层知识注入框架，通过逐步提供结构化上下文提高LLM在程序修复中的表现，实现79%的修复率，展示不同bug类型对上下文层次的需求差异。
2025-10-03 cs.SE
Arguzz: Testing zkVMs for Soundness and Completeness Bugs
提出首个自动化测试工具 Arguzz，通过结合蜕变测试变体与故障注入技术，有效检测 zkVMs 中的可靠性与完备性漏洞，在六个真实 zkVMs 中发现 11 个漏洞并获得高额赏金。
2025-09-13 cs.CR cs.PL cs.SE
Fix Bugs with Transformer through a Neural-Symbolic Edit Grammar
Iowa State University（爱荷华州立大学）；AWS AI（AWS人工智能）
我们介绍了NSEdit（神经符号编辑），一种新的基于transformer的代码修复方法。只给出包含bug的源代码，NSEdit预测可以修复bug的编辑序列。编辑语法被公式化为正则语言，并且Transformer将其用作神经符号脚本接口来生成编辑程序。我们修改Transformer并添加一个指针网络来选择编辑位置。训练重排序器的集合以重排序由束搜索生成的编辑序列。我们对验证集上的重排序器进行微调，以减少过度拟合。NSEdit在各种代码修复数据集上进行了评估，并在CodeXGLUE基准测试的Tufano小数据集上实现了新的最先进的精度（$24.04\%$）。NSEdit在程序因包而异以及有bug的程序是具体的情况下执行稳健。我们对我们的方法进行了详细的分析，并证明了每个组件的有效性。
2022-04-13 cs.AI cs.LG cs.PL
Modelling Concurrency Bugs Using Machine Learning
Imperial College of Science, Technology and Medicine（帝国理工学院）；Massachusetts Institute of Technology（麻省理工学院）
本研究比较常见与最新的机器学习方法，利用合成数据集模拟并发程序，验证模型类型的基本限制，以支持自动检测并发缺陷并提升工具准确性与语言灵活性。
2023-05-08 cs.LG cs.PL cs.SE
Can Automated Program Repair Refine Fault Localization?
软件缺陷在现代软件系统中普遍存在，并且众所周知难以手动调试。因此，大量的研究工作一直致力于自动化软件调试，包括自动故障定位和程序修复。然而，现有的故障定位技术通常是无效的，即使是最先进的程序修复技术，也只能修复一小部分真实世界的错误。虽然故障定位和程序修复是内在联系的，但我们观察到，在文献中，它们唯一的联系是程序修复技术通常使用现成的故障定位技术（例如，Ochiai）来确定用于修补的潜在候选语句/元素。在这项工作中，我们探索他们在另一个方向的联系，即，程序修复是否反过来有助于故障定位？通过这种方式，我们不仅为更强大的故障定位开辟了一个新的维度，而且将程序修复的应用范围扩展到所有可能的错误（而不仅仅是可以直接自动修复的错误）。我们设计了ProFL，一种简单的方法，使用补丁执行结果（来自程序修复）作为故障定位的反馈信息。在广泛使用的Defects 4J基准上的实验结果表明，基本的ProFL已经可以在Top-1内定位395个研究错误中的161个，而最先进的基于频谱和突变的故障定位技术最多在Top-1内定位117个。我们还证明了ProFL在不同设置下的有效性。最后，我们表明，ProFL可以通过无监督和监督学习进一步提高最先进的故障定位。
2019-10-03 cs.SE
FuzzyFlow: Leveraging Dataflow To Find and Squash Program Optimization Bugs
本文提出FuzzyFlow框架，利用数据流程序表示捕获可复现系统状态和优化影响范围，实现快速语义等价性检查，并通过最小化测试输入算法，在真实应用中实现高达528倍的优化测试和调试加速。
2023-06-28 cs.SE
MUZZ: Thread-aware Grey-box Fuzzing for Effective Bug Hunting in Multithreaded Programs
灰盒模糊测试由于其轻量级的测试工具、快速的覆盖反馈和动态调整策略，已经揭示了真实世界软件中成千上万的漏洞。然而，直接将灰盒模糊应用于依赖于输入的多线程程序可能效率极低。在实践中，多线程相关的错误通常隐藏在复杂的程序流中。同时，现有的灰盒模糊技术没有强调线程交织影响多线程程序的执行状态。因此，主流的灰盒模糊器不能有效地测试多线程程序中的问题段，尽管他们可能会获得高的代码覆盖率统计。为此，我们提出MUZZ，一个新的灰盒模糊技术，在多线程程序中的错误狩猎。MUZZ拥有三种新颖的线程感知插装，即面向覆盖插装、线程上下文插装和调度干预插装。在模糊化过程中，这些工具产生运行时反馈，以强调线程交织引起的执行状态。通过利用动态种子选择和执行策略中的反馈，MUZZ保留了更多有价值的种子，这些种子在多线程上下文中暴露了错误。我们在12个真实世界的软件程序上评估MUZZ。实验表明，MUZZ在多线程相关种子生成和并发漏洞检测方面优于AFL。此外，通过针对生成的种子重放目标程序，MUZZ还揭示了更多的并发错误（例如，数据竞争，线程泄漏）比AFL。MUZZ总共检测到8个新的并发漏洞和19个新的并发错误。在撰写本文时，已为报告的问题分配了4个CVE ID。
2020-07-31 cs.SE
