CN104750563A - 一种基于控制流图的内存泄漏自动修复方法 - Google Patents

Abstract

一种基于控制流图的内存泄漏自动修复方法，应用于计算机程序的内存泄露检测和自动修复，包括如下步骤：第一步：制作计算机程序的控制流图；第二步：根据所述控制流图进行内存泄露检测和修复；第三步：利用在控制流图中记录的代码位置信息，将添加到图中的修复代码映射回原计算机程序代码中。开发者可以使用本发明所述的方法自动修复计算机程序的内存泄漏，而不必担心修复错误或引入新错误。

Description

一种基于控制流图的内存泄漏自动修复方法

技术领域

本发明涉及基于控制流图的技术，具体为一种能够自动修复C语言内存泄漏的错误的方法，属于软件测试领域。

背景技术

（一）错误修复相关技术

近年来有很多关于错误修复的研究。例如，一些研究人员^[1,2,3]试图利用一些方法自动修复一般类型的错误。所使用的方法通常使用所违反的正确条件，修改代码以满足这些条件。该正确条件来源于测试用例^[2,3]，或诸如前置条件和后置条件的断言^[1]。在所述正确条件被说明后，通常使用演化算法来给出修复。例如，在Arcuri和Yao的工作^[2]中，计算机程序和测试用例同时演化，并相互影响。Weimer等人^[3]使用遗传算法的一种扩展形式来演化程序变体。另外，Weiet等人^[1]在状态图中基于类的布尔查询来使用状态的抽象表示。以上这些技术使用的正确条件通常是不适当的，并且很少保证正确性。另外，说明修复内存泄漏的正确条件（如测试用例或断言）也是困难的。

还存在一些修复特定类型错误的方法。例如，Jin等人^[4,5]的方法自动修复多种并发性错误。这些方法中没有关于内存泄漏的修复。

修复可能是不好的，并引入新的错误。Gu等人^[6]形式化了不佳修复的问题，并且定义了修复的两个维度。“覆盖”维度衡量了正确修复所有错误的广度，而“破坏”维度衡量修复后的计算机程序与原有行为的偏差。在本发明中，我们能够确保修复的正确性，也就是避免了“破坏”这个维度，同时尽可能提高“覆盖”维度。

（二）内存泄漏相关技术

有静态和动态两种方法来处理内存泄漏。静态方法主要用于内存泄漏的检测^{[7,8,9,10,11,12, 13]}。大多数检测算法只报告内存泄漏发生的位置。因为在大多数情况下，分配内存和发生内存泄漏的位置分布在完全不同的位置，开发人员要进行修复仍然需要很多工作。即便在Fastcheck^[10]中，它给出了内存分配的泄漏路径，这个信息仍然不足以提供修复。而且，所有这些方法都有假阳性错误，这让开发人员很难依赖这些方法来自动修复内存泄漏。

另外一种处理内存泄漏的静态方法是关于Java的内存管理^[14,15,16]。这些方法在Java字节码中插入专门的释放语句，以减少需要被垃圾回收器扫描的引用的数量并提高运行时性能。这些方法与本发明有相似之处，即通过静态分析插入释放语句。但是，很难把这些方法应用于C语言。这是因为，首先，在C语言中，必须保证没有双重释放，而在Java中不存在这个问题。而且，不能仅仅通过在这些技术中增加功能来解决双重释放的问题，因为双重释放与搜索策略紧密相关，必须重新设计算法。其次，现有技术都是直接修改Java字节码，而在C语言中必须修改源代码，因而可读性是一个重要的方面。因此，现有工作中的很多技术不能被使用。例如，频繁地插入临时变量在源代码级别是不能被接受的。最后，Java有垃圾回收器，任何未被释放的内存可以被其安全回收。而在C语言中，每个错误都是潜在重要的错误，而且报告是否完全修复是重要的。上述技术都没有提供这些功能。

处理内存泄漏使用最广泛的动态方法是垃圾回收机制^{[17,18,19,20]}，它给运行时带来开销。也有动态检测内存泄漏的方法^{[21,22,23,24,25,26]}，它提供了在运行时泄漏的内存分配的位置。然而，类似于静态检测技术，这些技术都无法提供帮助快速修复的有用信息。

一些研究人员意识到修复内存泄漏的重要性，并尝试从多个方面解决这个问题。LEAKPOINT^[27]试图提供帮助定位修复位置的信息，该信息不仅报告内存分配的位置，它也报告内存引用丢失的位置或被最后一次使用的位置。然而，修复泄漏需要考虑所有路径，这个信息并不足以保证自动生成修复。Rayside和Mendel^[28]使用对象所有权的分析来寻找和修复垃圾（内存被引用但从未被使用）。但是，正像名称所指出的，这个技术只能给出统计报告，并不是自动修复。Xu等人^[29]提出了使用三个不同等级的知识来帮助不了解计算机程序的开发人员快速发现错误的根源。这份工作也不能自动修复内存泄漏。上述方法均依赖动态分析，引入了运行时开销。

也存在关于其它内存相关错误的研究。例如，Caballero^[30]等人使用动态方法检测释放后使用和双重释放的错误，Demsky和Rinard^[31]使用基于规约的方法来自动修复数据结构。这些工作与本发明不同，不处理内存泄漏，并且使用了动态方法。Fischer等人^[32]提出基于语义的方法来修复文件打开/关闭和队列上溢/下溢错误。该方法关注语义，并没有给出方法的有效性或高效性。

发明内容

本发明的目的是提供一种基于控制流图的内存泄漏自动修复技术。本发明能够保证修复的正确性，修复正确性定义如下：

给定分配好的内存块c，一个正确的内存泄漏的修复是将一条释放语句s插入计算机程序中，使得下面三个条件在任何一个s被执行的路径被满足：

1.c在s之前被分配，s释放c。

2.没有其它释放c的释放语句。

3.在s的执行后没有其它c的引用，也就是说，c在插入点后死亡。

除了正确性，还要求尽早释放，这样当我们不需要使用内存块时，就将其释放。

本发明的技术方案如下：

一种基于控制流图的内存泄漏自动修复方法，应用于计算机程序的内存泄露检测和自动修复，包括如下步骤（参见图4）：

第一步：制作计算机程序的控制流图，根据现有技术[10]，即可将计算机程序转换为控制流图；

第二步：根据所述控制流图进行内存泄露检测和修复，包括：

-在控制流图上进行指针分析，并标注出分配结点和内存释放结点；

-内存泄漏检测：将控制流图中的边分为一定发生内存泄漏、可能发生内存泄漏和一定不发生内存泄漏三类；

-内存泄漏修复：分析变量的活跃度，在控制流图中一定发生内存泄漏的边添加修复代码；

第三步：利用在控制流图中记录的代码位置信息，将添加到图中的修复代码映射回原计算机程序代码中。

优选的，所述的内存泄漏自动修复方法，包括如下步骤：

1)构造计算机程序的控制流图；

2)在控制流图上进行指针分析；同时，在控制流图中标注出分配结点、内存释放结点；指针分析用于分析控制流图中指向同一块内存的指针；分析时，对于指针赋值语句，将赋值语句左侧被赋值的指针加入右侧赋值的指针所在的别名集合，并将该左侧指针从原集合中删掉；对于其他语句不进行操作；分析的结果是在控制流图中的每个结点前、后，都提供指针的别名集合；

3)内存泄漏检测：将控制流图中的边分为一定发生内存泄漏、可能发生内存泄漏和一定不发生内存泄漏三类；

4)内存泄漏修复：在控制流图中一定发生内存泄漏的边添加修复代码；添加修复代码有三个条件：a)在该边存在指向该内存块的指针；b)该边是“一定发生内存泄漏”这一类的边；c)在该边指向该内存块的指针是不活跃的；迭代运行步骤3）和4），直到不能再提供更多修复为止；

5)将控制流图映射回代码：利用在控制流图中记录的代码位置信息，将添加到控制流图中的修复代码映射回原计算机程序代码中。

本发明的有益效果：开发者可以使用本发明所述的方法自动修复计算机程序的内存泄漏，而不必担心修复错误或引入新错误。

附图说明

图1内存泄漏代码示例。图1中，第1行分配了内存，但在第27和29行计算机程序返回时没有释放内存，因而发生内存泄漏。本修复工具可在26、27行之间，以及27、28行之间加入修复，释放array指向的内存块。

图2示例代码对应的控制流图示例。其中，椭圆代表计算机程序中的语句，有向边代表计算机程序控制流的流向。有向边上的“*”和“0”分别代表分支条件被满足和不被满足。根据图2的控制流图可以分析内存泄漏发生的路径并进行修复。

图3示例控制流图（图2）的内存泄漏检测结果示例。每条边被标记以表示属于哪种分类。DF表示一定不发生内存泄漏的边，PS表示可能发生内存泄漏的边，UN表示一定发生内存泄漏的边。

图4本发明所述方法的流程示意图。

具体实施方式

本发明提供技术方案如下：

首先，基于计算机程序的控制流图，把计算机程序的分析转化为对控制流图的分析；进而在控制流图上给出修复；最后把控制流图上的修复转换回代码。具体描述如下：

1、控制流图构造：根据现有技术^[10]，将计算机程序转换为控制流图；例如，图1中代码，其控制流图如图2所示。

2、指针分析：在控制流图上，利用已有框架^[33]进行指针分析。同时，在控制流图中标注出分配结点、内存释放结点。指针分析用于分析控制流图中指向同一块内存的指针。分析时，对于指针赋值语句，则将赋值语句左侧被赋值的指针加入右侧赋值的指针所在的别名集合，并将该左侧指针从原集合中删掉；对于其他语句不进行操作。分析的结果是在控制流图中的每个结点前、后，都提供指针的别名集合（指向同一个内存块的指针的集合）。除了进行指针分析以外，使用启发式算法，例如有指针ptr，则在“if(ptr)”、“if(!ptr)”、“if(ptr==0)”或“if(ptr!=0)”后的ptr==0的分支将指针从别名集合中删除，这样做可以有效地避免多余的free代码，虽然这些多余的代码不影响程序正确性

3、内存泄漏检测：将控制流图中的边分为一定发生内存泄漏、可能发生内存泄漏和一定不发生内存泄漏三类。具体地，如果经过一条边的任意一条路径都经过内存分配结点，但不经过内存释放结点，则一定发生内存泄漏；如果经过一条边的任意一条路径都经过分配结点并且经过内存释放结点，则一定不发生内存泄漏；否则，这条边即可能发生内存泄漏。具体地，由malloc结点向下遍历，对可遍历到的边做如下标记：从free结点分别向上、向下遍历，如遇到一条边在经过某个结点后分成两条或多条边，则终止遍历，标记遍历过的边为DF（一定不发生内存泄漏的边）；从终止遍历的边按原方向继续遍历，标记遍历过的边为PS（可能发生内存泄漏的边）；其他被标记过的边为UN（一定发生内存泄漏的边）。

4、内存泄漏修复：在控制流图中一定发生内存泄漏的边添加修复代码。添加修复代码有三个条件：a)在该边存在指向该内存块的指针；b)该边是“一定发生内存泄漏”这一类的边。c)在该边指向该内存块的指针是不活跃的。变量活跃度分析^[34]是一种经典的静态分析方法，用于分析在任意一条语句的前、后位置，在该位置之后还有哪些变量可能被使用到。如果可能被使用到则称该被使用的变量在该位置是活跃的，否则不是活跃的。本方法在所有满足这三个条件的边中选择变量不活跃的最早的边修复，然后迭代运行本算法的3、4步，直到不能再提供更多修复为止。

5、控制流图映射回代码：利用在控制流图中记录的代码位置信息，将添加到控制流图中的修复代码映射回原计算机程序代码中。在控制流图中，插入的free语句前、后都有若干条语句，这些语句在构造控制流图时保存了它们在原计算机程序代码中的位置（起止行号和列号）。根据这些位置信息以及语句的类型（顺序语句、条件语句），即可把插入的修复代码插入原计算机程序中。插入时除了位置正确外，还要考虑语法细节。比如，条件语句中可能需要添加大括号（{}）。

由于保证修复正确性，分析采取保守策略。例如，当无法确定控制流图中的边是否一定发生内存泄漏时，就将之归为可能发生内存泄漏的一类。这样就保证了给出的修复一定是正确的，不保证能正确修复的则不予修复。另外，由于静态分析不能判断运行时代码是否会实际执行，所给出的修复在实际运行中可能是不会被执行到，实验部分将给出数据结果。

实施例1：

以图1为例，技术方案实现过程如下：

1、生成控制流图，如图2；

2、进行指针分析。分析后，在控制流图中每个结点前、后，都有指针的别名集合。例如，在return sum;这个结点之前，集合为{array}，表示array是一个指针，而且没有其他指针指向array所指向的内存块。

3、内存泄漏检测。分析结果如图3所示。

4、内存泄漏修复。在标记为UN的边中，每条边上都有指向内存块的指针array，但只有在“return0;”和“(printf(“%d”,sum));”这两条语句之前的标记为UN的边上array是不活跃的。因此，在这两条边添加修复代码“free(array);”。

5、控制流图映射回代码。在代码的26、27行之间添加“free(array);”，并在else后添加“{”，“return0;”后添加“}”。同时，在27、28行之间添加“free(array);”。

实施例2：

为了检验本发明的效果，选用SPEC2000测试程序集。SPEC2000包含多个程序集，49万余行代码，同时被多种静态检测内存泄漏的工具使用。

SPEC2000程序集信息如表1所示，利用本发明所述的方法对之进行内存泄露修复，修复率如表2所示，内存泄漏检测工具报告的信息如表3所示，修复开销如表4所示。

表1统计了SPEC2000的程序集信息，程序大小从1千行到20万行不等，函数个数从44个到2271个，含有内存分配的个数从1个到67个不等。

表2给出本内存泄漏修复工具的效果，“修复量”给出本工具修复的内存泄漏的个数。“被检测的最多个数”统计了所有当前的其他内存泄漏检测工具最多检测出的内存泄漏的个数。“百分比”计算修复量占最多检测个数的比例，“修复点”统计给出的修复位置的个数。“不必要修复个数”统计不可能被程序跑到的修复位置个数。

表3统计了已有其他内存泄漏检测工具检测出的内存泄漏的个数。括号外为正确检测的个数，括号内为检测错误的个数。

表4为本发明所述方法的时间和内存开销。

运行结果说明，本工具能高效修复相当数量的内存泄漏错误。

表1SPEC2000程序集信息

表2修复的内存泄漏的个数

表3内存泄漏检测工具报告的个数

表4时间和内存开销

参考文献

[1]Y.Wei,Y.Pei,C.A.Furia,L.S.Silva,S.Buchholz,B.Meyer,and A.Zeller.Automated fixing ofprograms with contracts.In ISSTA2010,pages61–72,2010.

[2]A.Arcuri and X.Yao.A novel co-evolutionary approach toautomatic software bug fixing.InIEEE Congress on EvolutionaryComputation,pages 162–168.IEEE,2008.

[3]W.Weimer,T.Nguyen,C.Le Goues,and S.Forrest.Automaticallyfinding patches using geneticprogramming.InICSE’09,pages364–374,2009.

[4]G.Jin,L.Song,W.Zhang,S.Lu,and B.Liblit.Automatedatomicity-violation fixing.InPLDI’11,pages389–400,2011.

[5]G.Jin,W.Zhang,D.Deng,B.Liblit,and S.Lu.Automatedconcurrency-bug fixing.In OSDI’12,pages 221–236,2012.

[6]Z.Gu,E.T.Barr,D.J.Hamilton,and Z.Su.Has the bugreally been fixed?In ICSE’10,pages55–64,2010.

[7]D.L.Heine and M.S.Lam.A practical flow-sensitive andcontext-sensitive c and c++ memoryleak detector.In PLDI’03,pages168–181,2003.

[8]Y.Xie and A.Aiken.Context-and path-sensitive memoryleak detection.In ESEC/FSE-13,pages 115–125,2005.

[9]B.Hackett and R.Rugina.Region-based shape analysis withtracked locations.In POPL’05,pages 310–323,2005.

[10]S.Cherem,L.Princehouse,and R.Rugina.Practical memoryleak detection using guardedvalue-flow analysis.In PLDI’07,pages480–491,2007.

[11]Y.Jung and K.Yi.Practical memory leak detector based onparameterized proceduralsummaries.In ISMM’08,pages131–140,2008.

[12]E.Torlak and S.Chandra.Effective interprocedural resourceleak detection.In ICSE’10,pages535–544,2010.

[13]Y.Sui,D.Ye,and J.Xue.Static memory leak detection usingfull-sparse value-flow analysis.InISSTA 2012,pages254–264,2012.

[14]S.Z.Guyer,K.S.McKinley,and D.Frampton.Free-me:astatic analysis for automaticindividual object reclamation.InPLDI’06,pages 364–375,2006.

[15]S.Cherem and R.Rugina.Uniqueness inference for compiletimeobject deallocation.InISMM’07,pages 117–128,2007.

[16]S.Cherem and R.Rugina.Compile-time deallocation of individualobjects.In ISMM’06,pages 138–149,2006.

[17]R.Jones and R.Lins.Garbage collection:algorithms for automaticdynamic memorymanagement.John Wiley & Sons,Inc.,New York,NY,USA,1996.

[18]H.-J.Boehm and M.Weiser.Garbage collection in an uncooperativeenvironment.Software:Practice and Experience,18(9):807–820,1988.

[19]P.Wilson.Uniprocessor garbage collection techniques.InMemory Management,volume 637,pages 1–42.SpringerBerlin Heidelberg,1992.

[20]H.-J.Boehm.Bounding space usage of conservative garbagecollectors.In POPL’02,pages93–100,2002.

[21]M.D.Bond and K.S.McKinley.Bell:bit-encoding onlinememory leak detection.InASPLOS-XII,pages 61–72,2006.

[22]W.DePauw and G.Sevitsky.Visualizing reference patternsfor solving memory leaks in java.InECOOP’99,pages 116–134,1999.

[23]M.Hauswirth and T.M.Chilimbi.Low-overhead memoryleak detection using adaptivestatistical profiling.In ASPLOSXI,pages156–164,2004.

[24]M.Jump and K.S.McKinley.Cork:dynamic memory leakdetection for garbage-collectedlanguages.In POPL’07,pages 31–38,2007.

[25]W.DePauw,D.Lorenz,J.Vlissides,and M.Wegman.Executionpatterns in object-orientedvisualization.In COOTS’98,pages 16–16,1998.

[26]G.Xu and A.Rountev.Precise memory leak detection forjava software using containerprofiling.In ICSE’08,pages151–160,2008.

[27]J.Clause and A.Orso.Leakpoint:pinpointing the causes ofmemory leaks.In ICSE,pages515–524,2010.

[28]D.Rayside and L.Mendel.Object ownership profiling:atechnique for finding and fixingmemory leaks.In ASE,pages194–203,2007.

[29]G.Xu,M.D.Bond,F.Qin,and A.Rountev.Leakchaser:helping programmers narrow downcauses of memory leaks.In PLDI’11,pages270–282,2011.

[30]J.Caballero,G.Grieco,M.Marron,and A.Nappa.Undangle:early detection of danglingpointers in use-after-free anddouble-free vulnerabilities.In ISSTA 2012,pages133–143,2012.

[31]B.Demsky and M.Rinard.Goal-directed reasoning forspecification-based data structure repair.IEEE Transactionson Software Engineering,32(12):931–951,2006.

[32]B.Fischer,A.Saabas,and T.Uustalu.Program repair assound optimization of brokenprograms.In TASE2009,pages165–173,2009.

[33]M.Hind,M.Burke,P.Carini,and J.-D.Choi.Interproceduralpointer alias analysis.ACM rans.Program.Lang.Syst.,21(4):848–894,1999.

[34]A.V.Aho,M.S.Lam,R.Sethi,and J.D.Ullman.Compilers:Principles,Techniques,andTools(2nd Edition).2006.

Claims (5)

1.一种基于控制流图的内存泄漏自动修复方法，其特征是，包括如下步骤：

第一步：制作计算机程序的控制流图；

第二步：根据所述控制流图进行内存泄露检测和修复，包括：

-在控制流图上进行指针分析，并标注出分配结点和内存释放结点；

-内存泄漏检测：将控制流图中的边分为一定发生内存泄漏、可能发生内存泄漏和一定不发生内存泄漏三类；

-内存泄漏修复：分析变量的活跃度，在控制流图中一定发生内存泄漏的边添加修复代码；

第三步：利用在控制流图中记录的代码位置信息，将添加到图中的修复代码映射回原计算机程序代码中。

2.如权利要求1所述的内存泄漏自动修复方法，其特征是，若无法确定控制流图中的边是否一定发生内存泄漏时，就将之归为可能发生内存泄漏的一类。

3.如权利要求1所述的内存泄漏自动修复方法，其特征是，如果不确定分析结果，则忽略该路径及其相关内存块。

4.如权利要求1所述的内存泄漏自动修复方法，其特征是，包括如下步骤：

1)构造计算机程序的控制流图；

2)在控制流图上进行指针分析；同时，在控制流图中标注出分配结点、内存释放结点；指针分析用于分析控制流图中指向同一块内存的指针；分析时，对于指针赋值语句，将赋值语句左侧被赋值的指针加入右侧赋值的指针所在的别名集合，并将该左侧指针从原集合中删掉；对于其他语句不进行操作；分析的结果是在控制流图中的每个结点前、后，都提供指针的别名集合；

3)内存泄漏检测：将控制流图中的边分为一定发生内存泄漏、可能发生内存泄漏和一定不发生内存泄漏三类；

4)内存泄漏修复：在控制流图中一定发生内存泄漏的边添加修复代码；添加修复代码有三个条件：a)在该边存在指向该内存块的指针；b)该边是“一定发生内存泄漏”这一类的边；c)在该边指向该内存块的指针是不活跃的；迭代运行步骤3）和4），直到不能再提供更多修复为止；

5)将控制流图映射回代码：利用在控制流图中记录的代码位置信息，将添加到控制流图中的修复代码映射回原计算机程序代码中。

5.如权利要求4所述的内存泄漏自动修复方法，其特征是，步骤3）中，在所述的控制流图中，如果经过一条边的任意一条路径都经过内存分配结点，但不经过内存释放结点，则一定发生内存泄漏；如果经过一条边的任意一条路径都经过分配结点并且经过内存释放结点，则一定不发生内存泄漏；否则，这条边为可能发生内存泄漏。