CN105808369A - 一种基于符号执行的内存泄漏检测方法 - Google Patents

Abstract

本发明针对内存泄漏缺陷，提出一种基于符号执行的内存泄漏检测方法，首先对于被测试的源代码，使用静态分析工具处理，得到静态内存泄漏警报；然后，把用源代码和内存泄漏警报，同时输入插桩器，得到插桩后的代码。接着，把插桩后的代码输入测试用例生成模块，生成大量测试用例并执行所有测试用例。每个测试用例运行结束后都有对目标内存对象泄漏情况汇报，最后综合所有测试执行的输出，对内存泄漏测试结果进行判定。本方法解决了静态内存泄漏分析的误报问题和动态测试的漏报问题，并利用符号执行技术生成测试用例，减少了静态分析内存泄漏结果的人工验证工作。提高了动态执行的效率。

Description

一种基于符号执行的内存泄漏检测方法

技术领域

本发明属于软件工程和软件测试领域，尤其涉及一种软件内存泄漏检测方法，主要利用符号执行技术来解决静态内存泄漏分析的误报问题和动态测试的漏报问题。

背景技术

在C/C++程序中，内存泄漏是指程序中动态分配的内存由于某种原因没有释放，导致系统无法再次分配该内存。内存泄漏分为两种情况：引用丢失和忘记释放。引用丢失是指失去了所有指向动态分配内存对象的指针或引用，使得该内存对象不可达。忘记释放是指动态分配的内存虽然有指针或引用可达，但在程序运行余下部分没有访问和释放。

静态分析内存泄漏不用实际运行程序，而是分析源代码的结构来检测内存泄漏。静态分析一般是先为代码建立模型，定义内存泄漏缺陷的模式，然后在代码中查询匹配预定义的错误模式，得到错误报告。动态分析方法通过实时监控内存的分配和访问状态来实现对内存泄漏缺陷的检测。一般采用插桩的方式在测试程序中插入监视代码，检查内存的分配，使用和释放情况。

符号执行指的是使用符号变量代替具体变量，不执行程序的前提下模拟程序执行来进行相关分析的技术。相对于给程序一个普通的输入，符号执行提供符号来表示任意的输入值。程序执行时把具体的操作替换为相应的符号操作。当程序运行到基于符号化变量的分支时，系统同时沿着两条路径运行，并在每条路径上维护一个称为路径条件的约束集合。路径条件表示程序沿着这条路径执行应满足的约束。当一条路径终止或遇到错误，把路径条件解析成具体值，能得到一个测试用例。如果把这个测试用例输入到原始的测试代码，它能沿着相同的路径执行并触发同样的错误。

LLVM是一个模块化和可重用的编译器的工具集合。它包含大量对C/C++源代码，中间代码的编译和优化处理工具。LLVMPass是一个用来实现程序的转换和优化的框架。Pass以LLVM中间代码作为输入，提供了大量API让程序员能够在中间代码级别上查找，插入和删除指令。

静态内存泄漏分析是按照代码的结构模型和规则来查找内存泄漏，由于模型的不完备性，只能尽可能多找到疑似内存泄漏的情况，因此会有很多误报。大量的静态分析的疑似内存泄漏警报，需要逐条人工验证，这个过程费时费力。而动态测试内存泄漏的方法，需要测试用例驱动测试，没有测试用例经过的代码就检查不出是否泄漏。而且由于没有目标，动态测试需要对整个被测代码插桩，运行效率不高。

发明内容

针对现有技术中存在的内存泄漏缺陷，本发明利用静态分析指导动态测试的混合方法，提出一种基于符号执行的内存泄漏检测方法，解决静态内存泄漏分析的误报问题和动态测试的漏报问题。

为了实现本发明的发明目的，本发明的技术方案为，一种基于符号执行的内存泄漏检测方法：首先对于被测试的源代码，使用静态分析工具处理，得到内存泄漏警报；然后把源代码和内存泄漏警报，同时输入插桩器，得到插桩后的代码；接着，把插桩后的代码输入测试用例生成模块，生成大量测试用例并执行所有测试用例。每个测试用例运行结束后都有对目标内存泄漏情况汇报，最后综合所有测试执行的输出，对内存泄漏测试结果进行判定。判定结果是在静态分析报告的基础上，进一步把内存泄漏分为MUST-LEAK，LIKELY-NOT-LEAK，BLOAT和MAY-LEAK四类。其中，MUST-LEAK类型表示该内存一定泄漏；LIKELY-NOT-LEAK表示该泄漏很可能是错的；BLOAT表示虽然该内存不太可能泄漏，但在疑似泄漏点之后没有访问，应该提前释放；最后没有测试用例覆盖到其路径的泄漏归为MAY-LEAK；最后只有MAY-LEAK类别需要人工验证。

本发明所述的基于符号执行的内存泄漏检测方法步骤如下：

1)对于被测试的源代码，使用静态分析工具处理，得到内存泄漏警报；

11)对静态分析工具输出的内存泄漏警报信息进行预处理，得到内存泄漏的位置信息和程序路径，整理成能识别的格式并保存在文件中；

12)一个静态分析内存泄漏警报记为p＝(a,l^b1 ₁,l^b2 ₂,…,e)，包括内存分配点a，分支点l^b和泄漏点e。分支点l^b的上标b∈{T,F},分别表示if语句的then分支和else分支。警报表示在程序点a分配的目标内存在e点之后可能失去所有引用发生内存泄漏；

2)对被测代码进行插桩，首先读取预处理过的内存泄漏警报，在代码中可能发生内存泄漏的位置进行插桩，记录所有内存的创建、访问和释放信息，并判断程序执行是否完整经过目标路径；

21)在程序开头和结尾的插桩分别是做初始化工作(内存泄漏报告的读取，数据结构的创建等)和收尾工作(结果输出)；

22)在所有目标内存分配指令后插桩，记录目标内存的创建信息；

23)在所有内存释放指令后插桩，判断目标内存是否释放；

24)在所有内存访问指令后插桩，判断目标内存释放访问过；

3)通过代码插桩，对程序的执行路径进行跟踪，来检查程序执行时经过了哪些目标路径，具体步骤如下：

31)读取所有内存泄漏警报的路径，每个路径点包含所在源代码文件名、行号和类型；

32)遍历被测代码所有指令，如果该指令所在文件名和行号属于目标路径，则插入函数调用指令调用插桩函数reportAtFortifyNode(文件名，行号)；

33)在reportAtFortifyNode(文件名，行号)中设置对应路径点执行到的标记，在所有内存泄漏报告的路径点，判断执行是否完整经过目标路径；

4)通过插桩代码，对目标内存进行跟踪和记录，来判断在一次测试执行后，该目标内存是否被访问和释放。定义一个状态机来描述目标内存的状态转换(见说明书附图3)：

41)每个目标内存在刚创建时处于CREATED状态；

42)如果之后程序执行经过它所在的内存泄漏路径上的泄漏点e，就把状态转换为LP；

43)在LP之后，如果程序依然访问了该目标内存，则把它的状态设置为USEDAFTERLP；

44)接着释放了该目标内存，则该目标内存没有泄漏，变成状态LNL(LIKELY-NOT-LEAK)；

45)如果目标内存在LP之后没有被访问，最后释放了，则进入状态BLOAT；

46)还有一种情况是，目标内存在程序还没执行到泄漏点时就释放了。把它标记为DFREED(直接释放)。

5)基于符号执行技术生成能够覆盖这些内存泄漏路径的测试用例，并运行测试用例，分析得到针对内存泄漏缺陷的测试结果。在静态分析报告的基础上，进一步把内存泄漏分为MUST-LEAK，LIKELY-NOT-LEAK,BLOAT和MAY-LEAK四类。其中，MUST-LEAK类型表示该内存一定泄漏；LIKELY-NOT-LEAK表示该泄漏很可能是错的；BLOAT表示虽然该内存不太可能泄漏，但在疑似泄漏点之后没有访问，应该提前释放；最后没有测试用例覆盖到其路径的泄漏归为MAY-LEAK；最后只有MAY-LEAK类别需要人工验证。

51)对一个警报，检查a分配的目标内存，在程序的结尾是否释放。只要存在一个测试用例的运行，经过完整的目标路径p之后，a点分配的目标内存在程序结尾处没有释放，则该内存一定泄漏，该警报就被归类为MUST-LEAK；

52)如果对每个测试用例的执行，在程序点a分配的目标内存在疑似的泄漏点e之后仍然被访问到，并且在程序结尾处都释放了，那么该内存发生泄漏的可能性就很低。无法保证该内存真的不泄漏，因此，把满足这种情况的测试结果称为LIKELY-NOT-LEAK(很可能不泄漏)；

53)除了上述两种情况，还有些目标内存虽然最后释放了，但是它们在疑似的泄漏点e之后没有访问过。这类目标内存占据着有限的内存资源却没有使用，也会对程序的运行效率造成影响。如果一个目标内存在某个程序点之后没有被访问，但最终被释放了，这种现象称为内存的BLOAT；

54)对一个内存泄漏警报，如果所有的测试用例都没有完整地覆盖对应的内存泄漏路径，就把这个泄漏归类为MAY-LEAK。

本发明具有如下的有益效果：

(1)本发明通过静态分析的预处理来指导动态测试，通过跟踪目标内存对象状态来动态确认内存泄漏，在动态执行时监控程序的位置变得明确，缩小监控范围，提高了动态执行的效率。

(2)本发明利用符号执行工具的符号执行能够自动产生测试用例，只要存在测试用例覆盖到目标路径，就能检测出内存泄漏。

(3)解决静态内存泄漏分析的误报问题和动态测试的漏报问题，并利用符号执行技术生成测试用例，减少了静态分析内存泄漏结果的人工验证工作。

附图说明

图1是本发明实施例的方法框架。

图2是本发明实施例的具体实现流程。

图3是本发明实施例的目标内存的状态转换示意图。

具体实施方式

以下结合说明书附图和具体实施例对本发明作进一步详细说明。

实施例：图2是图1中测试框架具体化后的过程，具体介绍基于符号执行的内存泄漏测试方法，表示了在LLVM框架下，用静态分析指导动态内存泄漏测试方法的工作流程。首先，把C语言代码输入静态分析工具Fortify，得到静态内存泄漏警报。同时，把源代码用llvm-gcc编译后，与泄漏警报一起输入LLVM中间代码(IR)插桩器(LLVMPass)，修改中间代码，做路径跟踪和内存对象状态跟踪等工作；接着，把插桩后的中间代码输入到KLEE中进行符号执行，生成测试用例；执行所有测试用例，收集目标内存的状态信息；最后综合所有测试用例的执行结果，得到4个类别的内存泄漏测试结果。

接下来分别介绍插桩、路径跟踪、内存对象状态跟踪和内存泄漏结果判定的具体方法。

一.插桩

插桩是本实施例的实现重点，所有的路径跟踪、内存对象状态跟踪都要通过插桩技术在代码中实现。

本实施例的插桩工作在LLVM平台上实现的，具体来说是LLVMPass框架。在测试代码的某些位置插入额外的可执行代码，最方便的方式是插入外部函数调用语句，然后在其它文件定义这些外部函数，最后把这些编译后的外部文件与插桩后的代码链接起来形成插桩后的可执行代码。

LLVMPass的插桩程序的编写：(1)在中间代码内创建插桩函数的声明；(2)在指定指令前后插入插桩函数调用语句。(3)编写C++代码实现具体的插桩函数的操作。

二.路径跟踪

要利用静态分析的警报对内存泄漏进行动态测试，重要的前提是找到覆盖内存泄漏路径的测试用例。符号执行时，很可能恰好没有产生经过某个目标路径的测试用例(例如，内存空间有限或该路径条件很难解析)。一个测试用例的执行，如果没有完整经过本发明想要测试的目标路径p(包括内存分配点a，所有分支节点，以及疑似的泄漏点e)，那么这个测试用例对该警报就是无效的。那么，对一个内存泄漏警报，如果所有的测试用例都没有完整地覆盖对应的内存泄漏路径，就把这个泄漏归类为MAY-LEAK，表示本发明没法判断该路径是否发生内存泄漏。

这里强调完整经过，如果只是部分覆盖到泄漏路径，就没有意义。原因有三种：(1)首先，如果执行没有经过内存分配点a，就没法记录目标内存的地址和大小，之后的跟踪都不可能；(2)或者，如果没有经过疑似泄漏点e，就没法判定e点是否发生了泄漏；(3)第三种情况，如果测试用例的执行没有完整经过目标路径的每个分支点，那么执行肯定经过了其它分支。这样的话，目标内存有可能在其它分支把指针引用传给了全局对象g，而在泄漏的目标分支上没有传给这个全局对象g。后来，全局对象g释放了目标内存。那么，经过目标分支路径的时候，该内存泄漏了，不经过时就没泄漏。所以，没有完整经过中间的分支点，也没法判断该内存是否泄漏。

所以，路径跟踪简单来说就是要检查程序执行时经过了哪些目标路径，具体步骤如下：

(1)读取所有内存泄漏警报的路径，每个路径点包含所在源代码文件名、行号和类型。

(2)遍历被测代码所有指令，如果该指令所在文件名和行号属于目标路径，则插入函数调用指令调用插桩函数reportAtFortifyNode(文件名，行号)。

(3)在reportAtFortifyNode(文件名，行号)中设置对应路径点执行到的标记。

本实施例为各条路径的每个节点设置一个标志位，只要程序执行到某个路径点，就在插桩函数中把对应路径点的标记设为true。第3步需要找到所有路径中满足相同文件名和行号的路径点做标记，因为不同路径可能含有相同的程序点。这样，在被测代码执行结束时，如果整条路径的标志都为true，则该路径完整覆盖。需要注意的是，由于要在被测代码执行的时候跟踪路径覆盖情况，就必须在被测试代码中增加全局的数据结构(比如标志位)。

三.内存对象状态跟踪

每个目标内存从创建时刻到程序结束，经历了多个状态。本实施例定义了一个状态机来描述目标内存的状态转换。

图3是目标内存对象的状态转换示意图，每个目标内存在刚创建时处于CREATED状态。如果之后程序执行经过它所在的内存泄漏路径上的泄漏点e，就把状态转换为LP。在LP之后，如果程序依然访问了该内存对象，则把它的状态设置为USEDAFTERLP。接着，释放了该内存，则该对象没有泄漏，变成状态LNL(LIKELY-NOT-LEAK)。如果内存对象在LP之后没有被访问，最后释放了，则进入状态BLOAT。还有一种情况是，目标内存对象在程序还没执行到泄漏点时就释放了，把它标记为DFREED(Directlyfreed)。

四.内存泄漏测试结果判定

(1)内存泄漏的判定规则

静态内存泄漏警报w可表示为一个3元组，

$w=(a,<l_1^{b1},l_2^{b2},...,l_n^{bn}>,e)$

包括内存分配点a，分支点l^b和泄漏点e。分支点l^b的上标b∈{T,F}，分别表示if语句的true分支和false分支。警报中的所有程序点组成一条程序执行路径。警报w表示在a点分配的内存对象(可能有多个)经过所有分支后，在e点失去所有引用。内存分配点a不一定处于整个路径的起点；疑似的内存泄漏点e却肯定处于路径的末尾，而且通常情况下是函数的return语句。

本实施例把内存泄漏的测试结果分为4类，如图3所示：

a)如果存在一个测试用例，使得警报w在a点分配的内存对象o最后没有释放，则该泄漏记为为MUST-LEAK.

b)如果对所有测试用例，都使得警报w在a点分配的内存对象o在e点之后被访问，且最后释放了，则该泄漏记为为LIKELY-NOT-LEAK。

c)如果对所有测试用例，使得警报w在a点分配的内存对象o释放了，且存在一个测试用例，使得o在e点之后没有被访问，则该泄漏记为为BLOAT。

d)如果对所有测试用例，使得程序执行没有经过警报w的完整路径，则该泄漏记为为MAY-LEAK。

(2)内存泄漏的判定方法

因为C语言运行同一代码行内写多个语句，或者在循环中多次动态分配内存，所以一个内存泄漏路径的内存分配点a，可能对应多个内存对象o。要在一次执行中，动态判定一个内存泄漏警报w的类别，必须综合w对应的所有内存对象的最终状态。

具体的判定步骤如下：

对一个内存泄漏警报遍历内存分配点a对应的所有目标内存：

(1)如果存在对象o，最后没有释放，即处于状态CREATED或LP或USEDAFTERLP，则w归类为MUST-LEAK。

(2)否则，如果存在对象o为BLOAT，则w归类为BLOAT。

(3)如果所有对象o都为LNL，则w归类为LIKELY-NOT-LEAK。

(4)如果该路径没有完全覆盖，则w归类为MAY-LEAK。

通过以上方法，能得到一次执行的内存泄漏测试结果。但由于一个程序一般会有多个内存泄漏，一次执行也不一定能覆盖所有内存泄漏路径，所以要综合所有测试用例的运行结果，得到最终内存泄漏测试结果。

想要得到最终内存泄漏情况，要对每个内存泄漏，统计它在不同测试用例执行后的测试结果，做最终判定。举个例子，如果一个程序有41个测试用例，其中20个测试用例输出显示w的类别为MAY-LEAK，即它们都没有覆盖到w的路径，而有20个测试用例显示w的类别为LIKELY-NOT-LEAK，还有一个测试用例显示为MUST-LEAK。则标记w的类别为MUST-LEAK。因为目标路径只是程序的一个路径片段，路径的末尾之后可能还有分支，一部分分支的最后使得目标内存释放了，而有一个分支通往的结果是它没有释放，则该内存还是发生了泄漏。同理，当BLOAT和LIKELY-NOT-LEAK同时出现时，把它标记为BLOAT。

本发明已以较佳实施例公开如上，但它们并不是用来限定本发明，凡不脱离本发明之精神和范围内，自当可作各种变化或润饰，因此本发明的保护范围应当以本申请的权利要求保护范围所界定的为准。

Claims (7)

1.一种基于符号执行的内存泄漏检测方法，其特征在于，包括以下步骤：

步骤1，对于被测试的源代码，使用静态分析工具处理，得到内存泄漏警报；

步骤2，对被测代码插桩：读取所述内存泄漏警报，在代码中可能发生内存泄漏的位置进行插桩，记录所有内存的创建、访问和释放信息；

步骤3，通过对被测代码插桩，对程序的执行路径进行跟踪，来检查程序执行时经过了哪些目标路径；

步骤4，根据插桩的输出结果，用一个状态机来判断在一次测试执行后，该目标内存是否被访问和释放；

步骤5，基于符号执行技术生成能够覆盖内存泄漏路径的测试用例，并运行测试用例，对内存泄漏的测试结果进行判定。

2.根据权利要求1所述的内存泄漏检测方法，其特征在于，步骤1进一步包括：

步骤11，对所述内存泄漏警报进行预处理，得到内存泄漏的位置信息和程序路径，整理成能识别的格式并保存在文件中；

步骤12，一个所述内存泄漏警报记为p＝(a,l^b1 ₁,l^b2 ₂,…,e)，包括内存分配点a，分支点l^b和泄漏点e；分支点l^b的上标b∈{T,F}，分别表示if语句的then分支和else分支；警报表示：内存分配点a在泄漏点e之后可能失去所有引用，发生内存泄漏。

3.根据权利要求1所述的内存泄漏检测方法，其特征在于，步骤2进一步包括：

步骤21，在程序开头插桩进行初始化工作，即内存泄漏报告的读取，数据结构的创建；在程序结尾插桩进行收尾工作，即结果输出；

步骤22，在所有内存分配指令后插桩，记录目标内存的创建信息；

步骤23，在所有内存释放指令后插桩，判断目标内存是否释放；

步骤24，在所有内存访问指令后插桩，判断目标内存释放访问过。

4.根据权利要求1所述的内存泄漏检测方法，其特征在于，步骤3进一步包括：

步骤31，读取所有所述内存泄漏警报的路径，以及每个路径点包含所在源代码文件名、行号和类型，插桩判断执行是否完整经过目标路径；

步骤32，遍历被测代码所有指令，如果该指令所在文件名和行号属于目标路径，则插入函数调用指令，调用插桩函数reportAtFortifyNode(文件名，行号)；

步骤33，在reportAtFortifyNode(文件名，行号)中设置对应路径点执行到的标记。

5.根据权利要求1所述的内存泄漏检测方法，其特征在于，步骤4进一步包括：

步骤41，定义一个状态机来描述目标内存的状态转换；每个目标内存在刚创建时处于CREATED状态；

步骤42，如果之后程序执行经过目标内存所在的内存泄漏路径上的泄漏点e，就把状态转换为LP；

步骤43，在LP之后，如果程序依然访问了目标内存，则将其状态转换为USEDAFTERLP；

如果目标内存被释放，则该对象没有泄漏，将其状态设置为LNL，即LIKELY-NOT-LEAK；

如果目标内存在LP之后没有被访问，而最终释放，则转换状态为BLOAT；

如果目标内存在程序尚未执行到泄漏点e时已释放，则标记为DFREED，即直接释放。

6.根据权利要求1所述的内存泄漏检测方法，其特征在于，步骤5的内存泄漏判定结果包括：MUST-LEAK，LIKELY-NOT-LEAK，BLOAT和MAY-LEAK；其中MAY-LEAK类别需要人工验证；

MUST-LEAK类型表示“该内存一定泄漏”；LIKELY-NOT-LEAK表示“该泄漏很可能是错的”；BLOAT表示“虽然该内存不太可能泄漏，但在疑似泄漏点之后没有访问，应该提前释放”；最后“没有测试用例覆盖到其路径的泄漏”归为MAY-LEAK。

7.根据权利要求6所述的内存泄漏检测方法，其特征在于，内存泄漏判定步骤为：

对所述内存泄漏警报，检查a点分配的目标内存在程序的结尾是否释放：若存在一个测试用例的运行，经过完整的目标路径p之后，a点分配的目标内存在程序结尾处没有释放，则其一定发生内存泄漏，该警报就被归类为MUST-LEAK；

若对每个测试用例的执行，在a点分配的目标内存在疑似的泄漏点e之后仍然被访问到，并且在程序结尾处都释放了，那么其有较低的可能性发生泄漏，称为LIKELY-NOT-LEAK；

若a点分配的目标内存最终释放，但在疑似的泄漏点e之后没有访问过，这类内存对象占据着有限的内存资源却没有使用，也会对程序的运行效率造成影响，称为BLOAT；

若所有的测试用例均没有完整地覆盖所述内存泄漏警报对应的内存泄漏路径，则称为MAY-LEAK。