S3：通过S3进行语法和语义指导修复合成：通过示例编程进行语法和语义指导修复合成

S3: Syntax- and semantic-guided repair synthesis via S3: Syntax- and semantic-guided repair synthesis via programming by examples
S3：通过S3进行语法和语义指导修复合成：通过示例编程进行语法和语义指导修复合成
作者信息

摘要

一类著名的程序自动修复技术是基于语义的。这类技术，例如Angelix，通过符号执行推断语义规范，然后使用程序合成来构造满足这些推断规范的新代码。然而，获得的规范自然是不完整的，这使得合成引擎面临一项困难的任务，即从许多可能的解决方案的稀疏空间中合成一个通用解决方案，这些解决方案与提供的规范一致，但不一定通用。我们介绍了S3，这是一个新的修复合成引擎，它利用示例编程方法来合成高质量的缺陷修复。
S3的新颖之处在于，它能够处理稀疏的搜索空间，从而创建更一般的修复：
（1）通过特定领域的语言定制和约束语法搜索空间的系统方法，
（2）在受约束的搜索空间上基于枚举的高效搜索策略，
（3）基于候选解决方案和原始buggy程序之间的语法和语义距离的度量的一些排名特征。
我们将S3的修复效果与最先进的合成引擎Angelix、Enumerative和CVC4进行了比较。S3可以成功且正确地修复至少三倍于最佳基线的错误，这些数据集包括小程序中的52个错误，以及现实世界中的大型程序中的100个错误。
关键词：程序修复、示例编程、归纳综合、符号执行

1.介绍

臭名昭著的是，修复Bug非常困难、耗时且成本高昂[5,46]。因此，自动化错误修复，以减少这项任务的繁重负担，将具有巨大的价值。自动程序修复已经成为一种趋势，最近大量的工作致力于解决这个问题[6,20,24-26,29,32,34-36,51,52]，激发了未来实际应用的希望。该领域一个值得注意的工作是基于语义的程序修复，最近在Angelix[36]中有所体现。这类技术使用语义分析（通常是动态符号执行）和一组测试用例来推断错误代码的行为规范，然后通过程序合成来构建符合这些规范的修复。这种方法最近被证明可以扩展到大型真实软件中的bug[36]。
虽然可伸缩性已经得到了很好的解决，但程序修复中的一个紧迫问题是补丁质量，有时会根据补丁的过度拟合或通用性进行量化[43]。生成的修复有时可能过度适合用于修复的测试，并且无法推广到不同的测试集。这可能是由于测试薄弱或不完整，甚至仅仅是维修技术的性质[19,43]。各种修复方法都存在过度装配的问题，包括GenProg[29]、RSRepair[39]和SPR[32]。Angelix[36]等基于语义的方法也不例外，最近的研究[27]部分显示了这一点。在程序修复领域，过度装配和补丁质量仍然是一个具有挑战性的问题。
补丁过度拟合的一个原因是修复搜索空间通常很稀疏，包含许多看似合理的解决方案，这些解决方案可能会导致有缺陷的程序通过给定的测试套件，但这可能仍然被判断为不正确[33]。因此，解决过度拟合问题的一种方法是将搜索空间限制为更可能泛化的补丁。提高输出补丁质量的其他策略包括更高粒度的变异算子[19] ，反模式[45]，基于历史的模式[28]，来自执行跟踪的反馈[8]，或文档分析[51]。Angelix[36]通过基于PartialMaxMT的约束求解[35]和基于组件的合成[16]急切地保留了buggy程序的原始语法结构。然而，光靠这样的强制执行可能还不够[8]。此外，将其他策略或标准纳入基于约束的综合方法并不明显，因为这样做通常需要新颖且往往复杂的约束编码（其他人已经指出了这个问题，参见[14]第7章或[45]第2节）。这促使设计一种新的修复合成技术，该技术可以整合各种限制或补丁生成标准，从而能够在受限空间中高效搜索可能更高质量的补丁。

我们提出了一个新的、可扩展的修复合成系统S3（语法和语义引导修复合成）。S3通过我们对三个主要组件的新颖设计，解决了合成可概括补丁的挑战：
（1）一种底层领域特定语言（DSL），它可以系统地定制和约束用于修复的语法搜索空间，
（2）在DSL定义的受限搜索空间上，采用有效的基于枚举的搜索策略，以找到满足正确性规范（例如，由测试套件导出的）的解决方案，以及
（3）除了提供的规范之外，还作为附加标准的排序函数，以对候选解决方案进行排序，从而更倾向于那些更可能推广的解决方案。我们的排名函数是由一种直觉引导的，即正确的补丁通常在语法和语义上接近原始程序，从而测量候选解决方案和原始错误程序之间的这种语法和语义距离。与其他基于约束的修复合成技术不同，我们的框架具有高度的设计可定制性，可以方便地包含新的排名功能——其设计灵感来自编程实例（PBE）合成方法[14]。
给定一个要修复的错误程序和一组测试用例（通过和失败），S3分两个主要阶段工作。
第一阶段自动将修复定位到一个或多个目标修复表达式（例如，分支条件、分配右侧等）。S3在测试用例上运行动态符号执行，通过关联表达式收集无故障执行路径。然后，它解决了收集的路径约束，以生成具体的表达式值，从而允许测试通过。这些以输入和期望输出示例表示的规范是合成阶段的输入。
合成阶段首先通过我们从SYNTH-LIB[3]扩展的DSL来限制解决方案的语法搜索空间。我们的扩展允许它指定一个起始草图，或者一个表达式，该表达式可以为S3提供关于可能的解决方案的线索。在这里，草图是修复中的原始buggy表达式。接下来，S3形成与草图大小相同的表达式的解决方案搜索空间。最后，它通过一系列接近指定草图的语法和语义距离的特征对候选解决方案进行排序。如果S3找不到任何与草图大小相同的解决方案，它会调查增量小于或大于草图的表达式，并重复该过程。
我们通过在两个数据集上比较S3的表达能力和它生成的补丁的质量，以及最先进的基线技术（Angelix[36]；Enumerative[3]和CVC4[41]两种可选的语法引导合成方法），来评估S3。第一个数据集包含52个小程序中的bug，这是翻译成Java[10]的IntroClass基准[30]的子集。1 IntroClass数据集只包含小程序，但为每个程序提供了两个高覆盖率测试套件，允许对修复质量进行独立评估。第二个数据集包括我们从GitHub收集的100个大型现实世界Java bug。我们专注于Java，并基于以下几个原因构建了一个真实世界Java bug的新数据集。首先，Java是最流行和使用最广泛的编程语言，其影响力正在迅速增长。2.其次，一个具有透明基本事实的真实数据集（由开发人员提交的修复程序）可以简化在缺少两个独立的高质量测试套件的情况下评估程序修复工具生成的修复程序正确性的关键过程。现有的基准测试通常包括许多修改行的错误修复，其中可能包括复杂的更改，例如新特性或代码重构[15]；即使是Defects4J[18]等精心策划的数据集也包含许多涉及大量行的更改。这使得对生成的补丁正确性的评估变得复杂。我们的数据集仅限于修复不到五行代码的bug，从而降低了复杂代码更改的风险。由于许多最先进的修复工具针对的是只需要少量更改行的缺陷[34–36]，我们的数据集足以评估当前的研究。

我们通过几种方式评估生成的维修的质量和正确性。对于类内错误，我们评估独立的测试套件（与基准测试一起提供的测试套件，以及我们生成的其他测试套件）的正确性，这些测试套件与用于指导修复的测试套件是分开的。我们使用开发者提供的补丁作为100个真实世界bug的基本事实。对于这些bug，**如果生成的补丁（1）在语法上与开发人员提供的补丁相同，或者（2）通过一些（基本）转换在语义上等效，我们认为它是正确的。**在这两个数据集上，S3的表现都明显优于基线。S3从第一个数据集中为52个bug中的22个生成正确的补丁；Angelix、Enumerative和CVC4可以分别为7、1和1个bug生成正确的补丁。在大型真实数据集上，S3为100个bug中的20个生成正确的补丁，而Angelix、Enumerative和CVC4分别只能为6个、6个和5个bug生成正确的补丁。

总之，我们的新贡献包括：
•我们提出了S3，一个可扩展的修复合成引擎，旨在合成可概括的修复我们提出了一种新的结合语法和语义指导的排名功能，以有效地综合高质量的修复。
·通过设计，这些新功能可以直接集成到S3中我们对基于语义的程序修复上下文中不同合成技术的有效性进行了大规模的实证研究。
·S3在生成的修复质量方面明显优于基线
我们提供了一个数据集，其中包含来自大型真实软件的多个漏洞，这些漏洞具有透明的基本事实，能够可靠地评估机器生成的补丁的正确性。