CN111858290B - 用于检测目标代码的内存泄漏路径的方法和设备 - Google Patents

用于检测目标代码的内存泄漏路径的方法和设备 Download PDF

Info

Publication number
CN111858290B
CN111858290B CN201910364845.1A CN201910364845A CN111858290B CN 111858290 B CN111858290 B CN 111858290B CN 201910364845 A CN201910364845 A CN 201910364845A CN 111858290 B CN111858290 B CN 111858290B
Authority
CN
China
Prior art keywords
vertex
point
state
target memory
path
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910364845.1A
Other languages
English (en)
Other versions
CN111858290A (zh
Inventor
肖枭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Qianhaiyuansan Technology Co ltd
Original Assignee
Shenzhen Qianhaiyuansan Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Qianhaiyuansan Technology Co ltd filed Critical Shenzhen Qianhaiyuansan Technology Co ltd
Priority to CN201910364845.1A priority Critical patent/CN111858290B/zh
Publication of CN111858290A publication Critical patent/CN111858290A/zh
Application granted granted Critical
Publication of CN111858290B publication Critical patent/CN111858290B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/366Software debugging using diagnostics
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

一种用于检测目标代码的内存泄漏路径的方法和设备,以所述目标内存对象的每个使用位置为顶点和以所述每个使用位置对应的控制流关系为有向边,因应于所述顶点和所述有向边产生关于所述目标内存对象的有向图,并在所述目标内存对象的内存申请使用点对应的有向图顶点设置一初始状态,因应于所述有向图的每个顶点的状态以转换触发特性传播的所述初始状态,并记录到达包含错误状态的顶点的路径为潜在内存泄漏路径,并将满足路径实现性条件的潜在内存泄漏路径写入内存泄漏路径报告。

Description

用于检测目标代码的内存泄漏路径的方法和设备
技术领域
本申请涉及计算机领域,具体地说,涉及一种用于检测目标代码的内存泄漏路径的技术。
背景技术
计算机内存是软件运行的必备资源。内存资源不足会导致软件运行异常,甚至导致***崩溃和退出。目前,各软件所用的内存资源通常是动态申请的,即当软件需要内存时向***申请,而不再需要内存时则将先前申请的内存释放以归还给***。若因为某种原因软件没有及时将内存资源归还***,此时便发生了内存的泄漏。尤其是对于需要长时间运行的软件而言,随着时间的推移***存会逐渐累积直至耗尽***所有的内存资源;由于***一般不能自行从内存泄漏中恢复,因此内存泄漏最终可能会导致***崩溃及退出。
针对上述内存泄漏的情形,现有的检测方式有动态和静态两种。动态检测是指对运行中的软件***进行监测,并报告已经发生的内存泄漏,这种检测方式无法在代码开发周期中尽早介入,且因依赖于实际运行环境而覆盖并不完全;静态检测是指在软件未运行的情况下针对代码的运行逻辑进行分析并发现内存泄漏点,可在代码开发周期中较早介入,并且覆盖也较为完全。
现有的内存泄漏静态分析方法主要有以下几种:
1)基于符号执行的静态分析技术,其以模拟程序执行的方式进行内存泄漏分析,缺点是时间和内存复杂度均很高,对大规模代码跨函数分析难以在合理时间内分析完成(例如4小时分析100万行代码);
2)基于模式匹配的静态分析技术,其基于提前定义的规则来寻找软件***中的内存泄漏点,仅对已经建模的模式有比较好的分析效果,而对于不在该模式中的内存泄漏则无效;
3)基于稀疏值传递图的内存泄漏检测方法,其基于稀疏值传递图进行分析,算法复杂度高,难以在合理时间内分析完成大规模的软件***。
发明内容
针对现有技术中的问题,本申请的目的在于提供一种用于检测目标代码的内存泄漏路径的方法和设备。
根据本申请的一实施例,提供一种用于检测目标代码的内存泄漏路径的方法,该方法包括以下步骤:
确定目标内存对象在目标代码中的所有使用位置;
以所述目标内存对象的每个使用位置为顶点和以所述每个使用位置对应的控制流关系为有向边,因应于所述顶点和所述有向边产生关于所述目标内存对象的有向图;
在所述目标内存对象的内存申请使用点对应的有向图顶点设置一初始状态,因应于所述有向图的每个顶点的状态以转换触发特性传播的所述初始状态,并记录到达包含错误状态的顶点的路径为潜在内存泄漏路径;以及
验证所有潜在内存泄漏路径的路径实现性,并将满足路径实现性条件的潜在内存泄漏路径写入内存泄漏路径报告。
根据本申请的一实施例,所述验证对所有潜在内存泄漏路径执行路径实现性的步骤,包括:
以一路径约束求解器对所有潜在内存泄漏路径中每条潜在内存泄漏路径的约束条件进行求解;
判定遗弃约束条件为不存在的潜在内存泄漏路径;
验证约束条件被判定为存在的潜在内存泄漏路径为满足路径实现性的条件。
根据本申请的一实施例,所述确定目标内存对象在目标代码中的所有使用位置的步骤包括执行目标内存对象的静态指针分析以确定所述目标内存对象的所有使用位置。
根据本申请的一实施例,所述确定目标内存对象在目标代码中的所有使用位置的步骤包括:
识别所述目标代码中对目标内存对象具有数据依赖的至少一个依赖变量;
因应于所述目标代码中关于所述目标内存对象的至少一条第一语句以及所述目标代码中关于所述依赖变量的至少一条第二语句以创建所述目标内存对象的使用点;
确定所述目标内存对象在所述目标代码中的所有使用位置,其中所述所有使用位置包括所述目标内存对象的使用点;
其中,在所述第一语句中所述目标内存对象被使用或定义及在所述第二语句中所述依赖变量被使用或定义。
根据本申请的一实施例,所述方法还包括:
当所述依赖变量为一函数的局部变量时,在该函数的退出位置创建所述目标内存对象的结束点;
其中所述所有使用位置包括所述目标内存对象的使用点,以及所述目标内存对象的结束点。
根据本申请的一实施例,所述方法还包括:当所述依赖变量为一函数的形式参数时,在该函数的退出位置创建所述目标内存对象的参数返回点;
其中,所述所有使用位置包括所述目标内存对象的使用点,以及所述目标内存对象的参数返回点。
根据本申请的一实施例,所述方法还包括:当所述使用点所对应的语句的分支条件处在所述语句的反向控制边沿上时,创建关于该分支条件的分支点;
其中所述所有使用位置还包括所述分支点。
根据本申请的一实施例,所述方法还包括:当所述结束点所对应的语句的分支条件处在所述语句的反向控制边沿上时,创建关于该分支条件的分支点;
其中所述所有使用位置还包括所述分支点。
根据本申请的一实施例,所述方法还包括:当所述参数返回点所对应的语句的分支条件处在该语句的反向控制边沿上时,创建关于该分支条件的分支点;
其中所述所有使用位置还包括所述分支点。
根据本申请的一实施例,所述以所述每个使用位置所对应的控制流关系为有向边的步骤,包括:
对所述目标代码的控制流图执行深度优先搜索,并以有向边连接关于所述目标内存对象的相邻顶点,直至遍历所述控制流图;
在每个分支点对应顶点的出边记录对应的分支选择,其中所述分支选择包括真或假。
根据本申请的一实施例,所述以所述每个使用位置所对应的控制流关系为有向边的步骤,包括:
创建第一有向边,其中,所述第一有向边由所述目标内存对象的第一依赖变量在第一函数的函数调用点,指向所述目标内存对象的第二依赖变量在第二函数所对应的使用点;
创建第二有向边,其中,所述第二有向边由所述目标内存对象的第二依赖变量在第二函数的参数返回点,指向所述目标内存对象的第一依赖变量在第一函数的函数调用点的后继使用点;
其中,所述第二函数由所述第一函数调用。
根据本申请的一实施例,所述因应于所述有向图的每个顶点的状态以转换触发特性传播的所述初始状态的步骤,包括:当顶点为状态转换触发顶点时,因应于所述当前顶点的状态转换触发特性,在所述顶点的状态集合中保存对应的转换后状态,并将所述转换后状态传播至所述顶点的后继顶点。
根据本申请的一实施例,所述因应于所述有向图的每个顶点的状态以转换触发特性传播的所述初始状态的步骤,包括:
将所述顶点所对应的状态传播至所述当前顶点的后继顶点,
直至遍历所述有向图;
在所述有向图的每一个汇点合并所述每一个汇点的状态以确定所述每一个汇点的状态集合。
根据本申请的另一实施例,提供了一种用于检测目标代码的内存泄漏路径的设备,其中,该设备包括:
处理器;以及
被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器执行以上所述方法的操作。
根据本申请的又一实施例,提供了一种存储指令的计算机可读介质,所述指令在被执行时使得***执行以上所述方法的操作。
与现有技术相比,本申请通过确定目标内存对象在目标代码中的所有使用位置而确定指针的数据依赖,基于该指针分析以及控制流分析构造有向图,并基于该有向图检测内存泄漏,时间和内存复杂度均优于现有的内存泄漏检测手段,尤其在分析大规模软件时可同时保持高精度和高性能。此外,本申请所提供的内存泄漏路径的检测方式先使用低精度算法(流敏感)选取潜在内存泄漏路径,再使用高精度算法(路径敏感)进行路径验证以检测内存泄漏,算法效率高。
附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显。
图1示出本申请一实施例的检测内存泄漏路径的方法流程;
图2A是本申请另一实施例的用于检测目标代码的内存泄漏路径的方法的流程图;
图2B至图2F分别示出本申请的一个实施例的子步骤流程;
图3是本申请另一实施例中代码的使用流图;
图4示出本申请另一实施例中代码的使用流图的构造过程;
图5示出本申请另一实施例中使用流图的顶点的状态转换模式;
图6示出本申请另一实施例中描述状态分析在函数内分析的算法;
图7示出本申请另一实施例中的假性内存泄漏路径;
图8示出可用于本申请各实施例的一种示例性***的功能模块。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的实施方式。相反,提供这些实施方式使得本申请将全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的结构,因而将省略对它们的重复描述。
根据本申请的一实施例,提供一种用于检测目标代码的内存泄漏路径的方法。总体而言,该方法以目标代码为输入,对目标代码进行数据依赖分析和控制依赖分析,并构建一有向图即使用流图(Use-Flow Graph,UFG),再基于该使用流图对目标代码进行状态分析以获得潜在的内存泄漏路径,之后验证潜在的内存泄漏路径的路径实现性以排除误报,并基于满足路径实现性的潜在内存泄漏路径生成内存泄漏路径报告以输出。图1示出了上述流程,其中在一些实施例中目标代码为程序中间码。在此,中间码(或中间语言、中间代码)是一种面向语法、易于翻译成目标程序的源程序的等效内部表示代码。
以下以一种用于检测目标代码的内存泄漏路径的计算设备(以下简称检测设备)为例,详细描述本申请的具体实施方式。
具体而言,参考图2A,该方法包括步骤S100、步骤S200、步骤S300和步骤S400。
在步骤S100中,检测设备确定目标内存对象在目标代码中的所有使用位置。在一些实施例中,一个程序中可能存在多个不同的变量名,而某些不同的变量名事实上可指向同一对象的指针。对目标代码进行的指针分析即用于分析程序中内存的值及其指向的对象,当其中一个指针状态出现变化时,程序分析算法能适时地改变另一指针的状态。而对目标代码的进行控制流分析用于分析程序中的控制流,以得到语句之间的互相可达性以及互相控制的关系,后续将详细展开。
在步骤S200中,检测设备以所述目标内存对象的每个使用位置为顶点和以所述每个使用位置对应的控制流关系为有向边,因应于所述顶点和所述有向边产生关于所述目标内存对象的有向图。在此,该有向图将被称为使用流图(Use-Flow Graph,UFG),其为本申请提出的一种数据格式和程序的表示形态。为清楚地描述该使用流图,以下给出一段示例性代码。
代码1
该示例性代码1中每行前面的数字编号代表相应的行号,相应的使用流图如图3所示。以下基于代码1及该使用流图进行说明。其中,该使用流图记录了变量的消失事件所发生的程序位置(上述“使用位置”)以及该消失事件发生时相应的变量和其他使用该对象的位置之间的控制流关系。例如,在图3中,“t@s9”表示t变量在第9行被***释放。而对于针对某个对象的使用流图而言,未使用该对象的程序点未被记录在相应的使用流图中,例如就上述代码中另一个变量q而言,其使用点均为记录在针对变量t的使用流图中。其中,目标内存对象的使用位置包括但不限于该目标内存对象的使用点、相应函数的结束点、参数返回点等,在该例中使用位置对应于相应的行号。使用流图还通过边连接起不同方法的子图,如图3中的t@s3->p@s10以及p@s12->t@s6,从而能够实现跨函数分析。
在步骤S300中,检测设备在所述目标内存对象的内存申请使用点对应的有向图顶点设置一初始状态,因应于所述有向图的每个顶点的状态以转换触发特性传播的所述初始状态,并记录到达包含错误状态的顶点的路径为潜在内存泄漏路径。例如,给顶点设置一初始状态,并将该状态在使用流图面进行传播,若遇到可以触发状态转换的顶点,则将转换后的状态保存于该顶点的状态集合中,而遇到普通的顶点则保持状态不变并将该状态传播至该顶点的连接点中,直至遍历该使用流图。
在步骤S400中,检测设备验证所有潜在内存泄漏路径的路径实现性,并将满足路径实现性条件的潜在内存泄漏路径写入内存泄漏路径报告。其中路径实现性算法具有路径敏感的精度,从而避免误报并实现对内存泄漏路径的精确检测。
其中在一些实施例中,参考图2B,以上所述的验证对所有潜在内存泄漏路径执行路径实现性的步骤,包括子步骤S410、子步骤S420和子步骤S430。在子步骤S410中,检测设备以一路径约束求解器对所有潜在内存泄漏路径中每条潜在内存泄漏路径的约束条件进行求解;在子步骤S420中,检测设备判定遗弃约束条件为不存在的潜在内存泄漏路径;在子步骤S430中,检测设备验证约束条件被判定为存在的潜在内存泄漏路径为满足路径实现性的条件。例如,***找到一条可能的内存泄漏路径为A->B->C。对于该内存泄漏路径,所谓约束条件是程序执行这条路径所满足的条件,如“a=1并且b=2并且c=4并且(e=5或者e=6)”;当这个条件可满足的时候,则称这条路径A->B->C可实现或满足路径实现性。另外,条件中包含如“a=5并且a=6”这样的冲突,显然“a=5并且a=6”无法满足,则称该约束条件无法满足,无解。在此,求解器是指求解约束条件所用的工具,例如微软的Z3求解器。
在一些实施例中,在以上所述的确定目标内存对象在目标代码中的所有使用位置的步骤中,检测设备执行目标内存对象的静态指针分析,以确定所述目标内存对象的所有使用位置。如上所述,一个程序中可能存在多个不同的变量名,而某些不同的变量名事实上可指向同一对象的指针。该静态指针分析即用于分析程序中内存的值及其指向的对象,当其中一个指针状态出现变化时,程序分析算法能适时地改变另一指针的状态。目标内存对象的使用位置包括但不限于该目标内存对象的使用点、相应函数的结束点、参数返回点等。
其中在一些实施例中,参考图2C,在上述确定目标内存对象在目标代码中的所有使用位置的步骤中,检测设备执行子步骤S110、子步骤S120和子步骤S130。具体而言,在子步骤S110中,检测设备识别所述目标代码中对目标内存对象具有数据依赖的至少一个依赖变量;在子步骤S120中,检测设备因应于所述目标代码中关于所述目标内存对象的至少一条第一语句以及所述目标代码中关于所述依赖变量的至少一条第二语句以创建所述目标内存对象的使用点;在子步骤S130中,检测设备确定所述目标内存对象在所述目标代码中的所有使用位置,其中所述所有使用位置包括所述目标内存对象的使用点。例如,对于每个内存对象v,算法首先搜索程序中所有数据依赖v的变量(表示为S(v))。以图3为例,变量t有内存分配点[t=malloc()],由于函数中的形式参数p数据依赖v,所以S(v)={p};在识别所有数据依赖的点后,即可开始构建使用流图的点和边。在此,所述内存对象v在所述第一语句中被定义或使用,而S(v)中的变量在所述第二语句中被定义或使用。
另外,在一些实施例中,当以上所述的依赖变量为一个函数的局部变量时,以上所述的所有使用位置除包括所述目标内存对象的使用点外,还包括所述目标内存对象所对应的结束点;因此,参考图2D,上述方法还包括步骤S140,在该步骤S140中,检测设备在该函数的退出位置创建所述目标内存对象的结束点,例如在S(v)中的变量是函数的局部变量时,在程序退出点创建v的结束点。
而当上述依赖变量为一个函数的形式参数时,以上所述的所有使用位置除包括所述目标内存对象的使用点外,还包括所述目标内存对象所对应的参数返回点;相应地,上述方法还包括步骤S150,在该步骤S150中,检测设备在该函数的退出位置创建所述目标内存对象的参数返回点,例如在S(v)中的变量是函数的形式参数时,在程序退出点创建v的参数返回点。
在完成上述的使用点、结束点和参数返回点的创建后,对于已经创建的每个点v@s(其中s表示一个程序语句),如果分支条件c处于s的反向控制边沿(Post-DominanceFrontier)上,则创建一个分支点v@c。具体来说,有以下三个方面:
(1)当所述使用点所对应的语句的分支条件处在所述语句的反向控制边沿上时,创建关于该分支条件的分支点;
(2)当所述结束点所对应的语句的分支条件处在所述语句的反向控制边沿上时,创建关于该分支条件的分支点;
(3)当所述参数返回点所对应的语句的分支条件处在该语句的反向控制边沿上时,创建关于该分支条件的分支点。
在以上三种情形下,检测设备所得到的分支点均应包含于上述“所有使用位置”之中。
以上解释了目标代码所对应的使用流图的顶点的创建过程。而对于目标代码而言,其使用流图的有向边将涉及函数的内边的建立;在有跨函数调用的情形存在时,使用流图的有向边还将涉及跨函数边的建立。以下分别从函数内边的建立和跨函数边的建立两方面,展开介绍使用流图的有向边的构造过程。
对于函数内边
在创建函数内边时,上述以所述每个使用位置所对应的控制流关系为有向边的步骤,参考图2E,包括子步骤S210和子步骤S220。在子步骤S210中,检测设备对所述目标代码的控制流图执行深度优先搜索,并以有向边连接关于所述目标内存对象的相邻顶点,直至遍历所述控制流图;在子步骤S220中,检测设备在每个分支点对应顶点的出边记录对应的分支选择,其中所述分支选择包括真或假。例如,通过在控制流图上做依次深度优先搜索,我们可以按顺序遍历图中的每一个点,并在遍历过程中将相邻的两个点通过有向边连接起来;同时,我们在分支点的出边上标注该分支的分支选择(c==true或者c==false)。
对于跨函数边
在创建跨函数边时,上述以所述每个使用位置所对应的控制流关系为有向边的步骤,包括子步骤S230和子步骤S240。在子步骤S230中,检测设备创建第一有向边,其中,所述第一有向边由所述目标内存对象的第一依赖变量在第一函数的函数调用点,指向所述目标内存对象的第二依赖变量在第二函数所对应的使用点;在子步骤S240中,检测设备创建第二有向边,其中,所述第二有向边由所述目标内存对象的第二依赖变量在第二函数的参数返回点,指向所述目标内存对象的第一依赖变量在第一函数的函数调用点的后继使用点。其中,所述第二函数由所述第一函数调用。
为清楚起见,以下将举例说明函数内边和跨函数边的创建过程。首先给出两段示例代码:
代码2
基于上述两段代码(代码2和代码3),对于每一个程序函数调用点CS:r=f(…,u,…)(u存在于S(v)中,且被用作该函数调用点的第k个实参),创建两个跨函数边:
-边1:[u@CS]->[pk->f](对应于上述第一有向边),其中pk表示f函数的第k个形式参数(对应于上述第一依赖变量),而代码2对应于上述第一函数,且代码2调用了代码3所对应的函数,被调用函数的形式参数则对应于上述第二依赖变量;
-边2:返回边[pk@end]->[u@s’](对应于上述第二有向边),其中pk@end表示函数f的第k个形式参数的参数返回点,而u@s’表示变量u在CS后紧接着的使用点(对应于上述后继使用点)。
相应的使用流图如图4所示,其中实线箭头代表函数内边(intra-proceduraledge),而虚线箭头代表跨函数边(inter-procedural edge)。
至此,目标代码的使用流图构建完成,检测设备可基于该使用流图分析目标代码的内存使用状况。在一些实施例中,参考图2F,以上所述的因应于所述有向图的每个顶点的状态以转换触发特性传播的所述初始状态的步骤,包括子步骤S310。在该子步骤S310中,当顶点为状态转换触发顶点时,检测设备因应于所述当前顶点的状态转换触发特性,在所述顶点的状态集合中保存对应的转换后状态,并将所述转换后状态传播至所述顶点的后继顶点。而当顶点非状态转换触发顶点时,将当前顶点的状态继续传播。因此,上述步骤包括子步骤S320和子步骤S330。在子步骤S320中,检测设备将所述顶点所对应的状态传播至所述当前顶点的后继顶点,直至遍历所述有向图;在子步骤S330中,检测设备在所述有向图的每一个汇点合并所述每一个汇点的状态以确定所述每一个汇点的状态集合。
举例来说,一些实施例使用有限自动状态机(Finite State Machine,FSM)(请参考图5)描述***内存的使用过程。该步骤使用状态分析以对程序中不同变量出现的状态进行分析,分析过程是基于使用流图(UFG)完成的。与已有的基于值传递图的分析相比而言,基于使用流图进行状态分析有如下特点:
(1)使用流图对整个变量的生命周期都做了建模,且仅对程序中使用该对象的位置进行建模,极大地提升了分析效率;
(2)已有的图构建算法可在线性时间内构建出一个程序的使用流图,因此图的构建效率也得到极大提高。
基于该有限自动状态机检测内存泄漏的方法是,通过跨函数的方式来遍历使用流图(UFG),并在遍历的过程中,分别使用一个集合来保存每个顶点的状态。具体而言,在内存申请的程序点,给该顶点设置一个A(Allocated,已申请)状态,然后将该状态在使用流图(UFG)上进行传播;若在传播过程中碰到了可以触发状态转换的顶点,则将转换后的状态保存于该顶点的状态集合中,而对于普通顶点而言则保持状态不变并将该状态传播至该普通顶点的连接点中。在每一个图汇合点,将不同路径的状态进行合并。最终,***将得到该对象在每一个顶点上的状态;若状态中存在错误(Error)状态,则将到达该错误点的路径记录为潜在内存泄漏路径。
图6示出一种描述状态分析在函数内分析时的算法。针对上述算法,表1示出了对代码1(请参照上文)进行分析时每一步中目标对象的状态值。
表1
如在最后一步中出现了“E”状态(Error),则该分析判定对象t有泄漏风险,并记录出现路径E的程序路径条件。
具体而言,表1示出了基于使用流图分析代码1(其使用流图对应于图3)的各个步骤。表格的每一列示出了接触一个顶点前和接触该顶点后的状态集合。例如,结合图5,在第5步和第7步,由于程序点s12和s7是来源于不同路径的两个状态集合相汇合的控制边,可用集合的并操作合并这两个状态集合。而在第8步中,由于程序点s9代表了堆对象t的范围边界,状态A(Allocated)转换为状态E(Error),而状态F(Freed)转换为状态X(eXit)。既经“超出范围”操作获得状态E,***即可报告潜在的内存泄漏路径。因为基于上述使用流图得到的某些潜在的内存泄漏路径其实是不可行(infeasible)的,这就可能形成图7所示的(沿虚线箭头方向)的假性内存泄漏路径。因此,为减少或消除误报,本申请引入路径敏感的路径实现性验证算法,由使用流图得到的潜在的内存泄漏路径稍后将在该路径实现性验证算法中进行验证。在路径实现性验证过程中,检测设备将验证如上所得的潜在内存泄漏路径的路径实现性。该验证算法具有路径敏感的精度,使用约束求解器求解路径中的约束条件。若一条路径被判定为不可行(infeasible)则将其遗弃,而若一条路径被判定为可行(feasible)则整个***认为是一条内存泄漏路径,并随后将其渲染并输出至内存泄漏路径报告。
实际上,一方面上述状态分析仅产生有限个潜在内存泄漏路径(因为实际上多数的堆内存空间被安全地管理),而另一方面一条路径的约束条件常常会包括明显的矛盾(例如,“a并且(非a)”,如图7所示,这是因为编程者倾向于使用直接的约束条件来满足一些逻辑特性),因此引入额外的路径敏感的路径实现性算法不仅不会增加成本,反而能使检测内存泄漏路径的过程更高效,在一些实施例中可减少80%以上的误报。因此,可首先采用线性时间求解器(linear-time solver)以检测一些明显不成立的约束条件,从而滤除显然不可行的路径。对于剩下的复杂情形,则采用全功能的SMT(Satisfiability Modulo Theories,可满足性模块理论)求解器(例如Z3求解器)进行解算以检查路径的可行性。线性时间求解器持续收集路径构建过程中的原子性约束。其中原子性约束是一阶逻辑公式,不包含任何类似“与”“或”“非”之类的逻辑运算符。例如,“a<2b”和“c”是“(a<2b)与c”的两个原子性约束。若一条路径的两个集合均包含原子性约束a,该路径必然包含“a”和“非a”,因此该路径不满足约束条件。
其中,图7所对应的示例性代码如下:
代码4
/>
本申请还提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机代码,当所述计算机代码被执行时,如前任一项所述方法的操作被执行。
本申请还提供了一种计算机程序产品,当所述计算机程序产品被计算机设备执行时,如前任一项所述方法的操作被执行。
本申请还提供了一种计算机设备,所述计算机设备包括:
一个或多个处理器;
存储器,用于存储一个或多个计算机程序;
当所述一个或多个计算机程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现如前任一项所述方法的操作。
图8示出了被用于实施本申请中所述实施例的示例性电子装置。
如图8所示,在一些实施例中,电子装置1000为所述实施例中的用于检测目标代码的内存泄漏路径的计算机设备。在一些实施例中,电子装置1000包括具有指令的一个或多个计算机可读介质(例如,存储器或NVM/存储设备1020)以及与该一个或多个计算机可读介质耦合并被配置为执行指令以实现模块从而执行本申请中所述方法的一个或多个处理器(例如,处理器1005)。
于本申请一个实施例,控制模块1010包括接口控制器,以向至少一处理器1005和/或与控制模块1010通信的设备或组件提供接口。
控制模块1010可包括存储器控制器模块1030,以向存储器1015提供接口。存储器控制器模块1030包括硬件模块、软件模块和/或固件模块。
于一个实施例中,存储器1015被用于为电子装置1000加载和存储数据和/或指令。于另一个实施例中,存储器1015包括易失性存储器,例如,DRAM。在一些实施例中,存储器1015包括双倍数据速率类型四同步动态随机存取存储器(DDR4SDRAM)。
于一个实施例中,控制模块1010包括一个或多个输入/输出(I/O)控制器,以向NVM/存储设备1020及(一个或多个)通信接口1025提供接口。
例如,NVM/存储设备1020被用于存储数据和/或指令。NVM/存储设备1020包括任意适当的非易失性存储器(例如,闪存)和/或包括任意适当的(一个或多个)非易失性存储设备(例如,一个或多个硬盘驱动器(Hard Disk,HDD)、一个或多个光盘(CD)驱动器和/或一个或多个数字通用光盘(DVD)驱动器)。
NVM/存储设备1020包括在物理上作为电子装置1000被安装在其上的设备的一部分的存储资源,或者其被该设备访问而不必作为该设备的一部分。例如,NVM/存储设备1020通过网络经由(一个或多个)通信接口1025进行访问。
(一个或多个)通信接口1025为电子装置1000提供接口以通过一个或多个网络和/或与任意其他适当的设备通信。电子装置1000根据一个或多个无线网络标准和/或协议中的任意标准和/或协议来与无线网络的一个或多个组件进行无线通信。
于一个实施例,(一个或多个)处理器1005中的至少一个与控制模块1010的一个或多个控制器(例如,存储器控制器模块1030)的逻辑封装在一起。于一个实施例,(一个或多个)处理器1005中的至少一个与控制模块1010的一个或多个控制器的逻辑封装在一起以形成***级封装(SiP)。于一个实施例,(一个或多个)处理器1005中的至少一个与控制模块1010的一个或多个控制器的逻辑集成在同一模具上。于一个实施例,(一个或多个)处理器1005中的至少一个与控制模块1010的一个或多个控制器的逻辑集成在同一模具上以形成片上***(SoC)。
在各个实施例中,电子装置1000包括:服务器、工作站、台式计算设备或移动计算设备(例如,膝上型计算设备、手持计算设备、平板电脑、上网本等)。在各个实施例中,电子装置1000可具有更多或更少的组件和/或不同的架构。例如,在一些实施例中,电子装置1000包括一个或多个摄像机、键盘、液晶显示器(LCD)屏幕(包括触屏显示器)、非易失性存储器端口、多个天线、图形芯片、专用集成电路(ASIC)和扬声器。
需要注意的是,本申请的实施例在软件和/或软件与硬件的组合体中被实施,例如,专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中,本申请的软件程序通过处理器执行以实现上文所述步骤或功能。同样地,本申请的软件程序(包括相关的数据结构)被存储到计算机可读记录介质中,例如,RAM存储器,磁或光驱动器或软磁盘及类似设备。另外,本申请的一些步骤或功能可采用硬件来实现,例如,作为与处理器配合从而执行各个步骤或功能的电路。
另外,本申请的一部分可被应用为计算机程序产品,例如计算机程序指令,当其被计算机执行时,通过该计算机的操作,可以调用或提供根据本申请的方法和/或技术方案。本领域技术人员应能理解,计算机程序指令在计算机可读介质中的存在形式包括但不限于源文件、可执行文件、安装包文件等,相应地,计算机程序指令被计算机执行的方式包括但不限于:该计算机直接执行该指令,或者该计算机编译该指令后再执行对应的编译后程序,或者该计算机读取并执行该指令,或者该计算机读取并安装该指令后再执行对应的安装后程序。在此,计算机可读介质可以是可供计算机访问的任意可用的计算机可读存储介质或通信介质。
以上内容是结合具体的优选实施方式对本申请所作的进一步详细说明,不能认定本申请的具体实施只局限于这些说明。对于本申请所属技术领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本申请的保护范围。

Claims (15)

1.一种用于检测目标代码的内存泄漏路径的方法,其中,该方法包括以下步骤:
确定目标内存对象在目标代码中的所有使用位置;所述目标内存对象包括变量,所述使用位置包括:变量在所述目标代码中的使用点、结束点、参数返回点或分支点中的一种或多种的组合;
以所述目标内存对象的每个使用位置为顶点和以所述每个使用位置对应的控制流关系为有向边,因应于所述顶点和所述有向边产生关于所述目标内存对象的有向图;
在所述目标内存对象的内存申请使用点对应的有向图顶点设置一初始状态,因应于所述有向图的每个顶点的状态以转换触发特性传播的所述初始状态,并记录到达包含错误状态的顶点的路径为潜在内存泄漏路径;以及
验证所有潜在内存泄漏路径的路径实现性,并将满足路径实现性条件的潜在内存泄漏路径写入内存泄漏路径报告;
所述因应于所述有向图的每个顶点的状态以转换触发特性传播的所述初始状态,并记录到达包含错误状态的顶点的路径为潜在内存泄漏路径,包括:
为所述有向图中的内存申请使用点对应的当前顶点设置一初始状态,针对当前顶点,将当前顶点的初始状态在所述有向图内进行传播,若遇到可以触发状态转换的第一顶点,将转换后的状态保存于该第一顶点的状态集合中,若遇到非状态转换触发的第二顶点,将该第二顶点的状态继续传播,直至遍历所述有向图;
获取所述有向图中每个顶点的状态集合,若任一顶点的状态集合中存在错误状态,则将到达该存在错误状态的顶点的路径记录为潜在内存泄漏路径。
2.根据权利要求1所述的方法,其中,所述验证对所有潜在内存泄漏路径执行路径实现性的步骤,包括:
以一路径约束求解器对所有潜在内存泄漏路径中每条潜在内存泄漏路径的约束条件进行求解;
判定遗弃约束条件为不存在的潜在内存泄漏路径;
验证约束条件被判定为存在的潜在内存泄漏路径为满足路径实现性的条件。
3.根据权利要求1所述的方法,其中,所述确定目标内存对象在目标代码中的所有使用位置的步骤包括:
执行目标内存对象的静态指针分析以确定所述目标内存对象的所有使用位置。
4.根据权利要求1所述的方法,其中,所述确定目标内存对象在目标代码中的所有使用位置的步骤包括:
识别所述目标代码中对目标内存对象具有数据依赖的至少一个依赖变量;
因应于所述目标代码中关于所述目标内存对象的至少一条第一语句以及所述目标代码中关于所述依赖变量的至少一条第二语句以创建所述目标内存对象的使用点;
确定所述目标内存对象在所述目标代码中的所有使用位置,其中所述所有使用位置包括所述目标内存对象的使用点;
其中,在所述第一语句中所述目标内存对象被使用或定义及在所述第二语句中所述依赖变量被使用或定义。
5.根据权利要求4所述的方法,其中,所述方法还包括:
当所述依赖变量为一函数的局部变量时,在该函数的退出位置创建所述目标内存对象的结束点;
其中所述所有使用位置包括所述目标内存对象的使用点,以及所述目标内存对象的结束点。
6.根据权利要求4所述的方法,其中,所述方法还包括:
当所述依赖变量为一函数的形式参数时,在该函数的退出位置创建所述目标内存对象的参数返回点;
其中,所述所有使用位置包括所述目标内存对象的使用点,以及所述目标内存对象的参数返回点。
7.根据权利要求4所述的方法,其中,所述方法还包括:
当所述使用点所对应的语句的分支条件处在所述语句的反向控制边沿上时,创建关于该分支条件的分支点;
其中所述所有使用位置还包括所述分支点。
8.根据权利要求5所述的方法,其中,所述方法还包括:
当所述结束点所对应的语句的分支条件处在所述语句的反向控制边沿上时,创建关于该分支条件的分支点;
其中所述所有使用位置还包括所述分支点。
9.根据权利要求6所述的方法,其中,所述方法还包括:
当所述参数返回点所对应的语句的分支条件处在该语句的反向控制边沿上时,创建关于该分支条件的分支点;
其中所述所有使用位置还包括所述分支点。
10.根据权利要求1所述的方法,其中,所述以所述每个使用位置所对应的控制流关系为有向边的步骤,包括:
对所述目标代码的控制流图执行深度优先搜索,并以有向边连接关于所述目标内存对象的相邻顶点,直至遍历所述控制流图;
在每个分支点对应顶点的出边记录对应的分支选择,其中所述分支选择包括真或假。
11.根据权利要求1或10所述的方法,其中,所述以所述每个使用位置所对应的控制流关系为有向边的步骤,包括:
创建第一有向边,其中,所述第一有向边由所述目标内存对象的第一依赖变量在第一函数的函数调用点,指向所述目标内存对象的第二依赖变量在第二函数所对应的使用点;
创建第二有向边,其中,所述第二有向边由所述目标内存对象的第二依赖变量在第二函数的参数返回点,指向所述目标内存对象的第一依赖变量在第一函数的函数调用点的后继使用点;
其中,所述第二函数由所述第一函数调用。
12.根据权利要求1所述的方法,其中,所述因应于所述有向图的每个顶点的状态以转换触发特性传播的所述初始状态的步骤,包括:
当顶点为状态转换触发顶点时,因应于所述顶点的状态转换触发特性,在所述顶点的状态集合中保存对应的转换后状态,并将所述转换后状态传播至所述顶点的后继顶点。
13.根据权利要求1所述的方法,其中,所述因应于所述有向图的每个顶点的状态以转换触发特性传播的所述初始状态的步骤,包括:
将所述顶点所对应的状态传播至所述顶点的后继顶点,
直至遍历所述有向图;
在所述有向图的每一个汇点合并所述每一个汇点的状态以确定所述每一个汇点的状态集合。
14.一种用于检测目标代码的内存泄漏路径的设备,其中,该设备包括:
处理器;以及
被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器执行根据权利要求1至13中任一项所述方法的操作。
15.一种存储指令的计算机可读介质,所述指令在被执行时使得***执行根据权利要求1至13中任一项所述方法的操作。
CN201910364845.1A 2019-04-30 2019-04-30 用于检测目标代码的内存泄漏路径的方法和设备 Active CN111858290B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910364845.1A CN111858290B (zh) 2019-04-30 2019-04-30 用于检测目标代码的内存泄漏路径的方法和设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910364845.1A CN111858290B (zh) 2019-04-30 2019-04-30 用于检测目标代码的内存泄漏路径的方法和设备

Publications (2)

Publication Number Publication Date
CN111858290A CN111858290A (zh) 2020-10-30
CN111858290B true CN111858290B (zh) 2024-02-06

Family

ID=72965092

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910364845.1A Active CN111858290B (zh) 2019-04-30 2019-04-30 用于检测目标代码的内存泄漏路径的方法和设备

Country Status (1)

Country Link
CN (1) CN111858290B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113326187B (zh) * 2021-05-25 2023-11-24 扬州大学 数据驱动的内存泄漏智能化检测方法及***
CN113326402B (zh) * 2021-06-16 2022-07-19 上海哔哩哔哩科技有限公司 有向无环图生成方法及***
CN113535150B (zh) * 2021-07-29 2023-09-22 北京大学 一种针对dram/nvm混合内存的无内存泄漏编程方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008282174A (ja) * 2007-05-09 2008-11-20 Matsushita Electric Ind Co Ltd 情報処理装置、情報処理方法、および情報処理プログラム
CN102279804A (zh) * 2011-08-16 2011-12-14 天津市天祥世联网络科技有限公司 视频监控平台***的内存池结构及实现方法
CN103440196A (zh) * 2013-07-11 2013-12-11 大连交通大学 一种新型操作***资源问题检测方法
CN104750563A (zh) * 2013-12-26 2015-07-01 北京大学 一种基于控制流图的内存泄漏自动修复方法
CN105787367A (zh) * 2016-02-23 2016-07-20 华中科技大学 一种软件更新的补丁安全性检测方法及***
CN107992386A (zh) * 2017-11-23 2018-05-04 上海斐讯数据通信技术有限公司 一种路由器内存压力测试方法及***

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7853930B2 (en) * 2005-01-04 2010-12-14 International Business Machines Corporation Annotating graphs to allow quick loading and analysis of very large graphs

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008282174A (ja) * 2007-05-09 2008-11-20 Matsushita Electric Ind Co Ltd 情報処理装置、情報処理方法、および情報処理プログラム
CN102279804A (zh) * 2011-08-16 2011-12-14 天津市天祥世联网络科技有限公司 视频监控平台***的内存池结构及实现方法
CN103440196A (zh) * 2013-07-11 2013-12-11 大连交通大学 一种新型操作***资源问题检测方法
CN104750563A (zh) * 2013-12-26 2015-07-01 北京大学 一种基于控制流图的内存泄漏自动修复方法
CN105787367A (zh) * 2016-02-23 2016-07-20 华中科技大学 一种软件更新的补丁安全性检测方法及***
CN107992386A (zh) * 2017-11-23 2018-05-04 上海斐讯数据通信技术有限公司 一种路由器内存压力测试方法及***

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"JSWhiz: Static analysis for JavaScript memory leaks";Jacques A.Pienaar等;《Proceedings of the 2013 IEEE/ACM International Symposium on Code Generation and Optimization》;1-11页 *
"基于静态检测的C++内存泄漏分析";陈贝等;《计算机工程与科学》;118-124页 *

Also Published As

Publication number Publication date
CN111858290A (zh) 2020-10-30

Similar Documents

Publication Publication Date Title
CN109426723B (zh) 使用释放后内存的检测方法、***、设备及存储介质
US7650595B2 (en) Sound transaction-based reduction without cycle detection
CN111858290B (zh) 用于检测目标代码的内存泄漏路径的方法和设备
US8732669B2 (en) Efficient model checking technique for finding software defects
US10423518B2 (en) Systems and methods for analyzing violations of coding rules
Alur et al. Model checking of hierarchical state machines
US8099696B2 (en) Method for providing information associated with an over-constrained event in verification of a circuit design
JP2022501734A (ja) ソフトウェアシステムで原因および結果を決定的に報告する方法
US20060150160A1 (en) Software analyzer
EP2718820B1 (en) Identifying and triaging software bugs through backward propagation of under-approximated values and empiric techniques
EP3185027B1 (en) Information processing method and device and computer storage medium
US20110029960A1 (en) Encapsulating and managing diagnostic information
US20070168741A1 (en) Method, system and program product for facilitating debugging of simulation results obtained for an optimized simulation model of a device design having hierarchically-connected components
CN114168222B (zh) 一种启动耗时的获取方法、装置、终端设备和存储介质
US8898649B2 (en) Application program analysis method, analysis system and recording medium for identifying a contributing factor for an invalid operation of an application program
CN117907812B (zh) 电路检测方法及装置、电子设备、存储介质、程序产品
WO2023207973A1 (zh) 编译器测试方法、用例生成方法、装置及指令存储结构
US9646252B2 (en) Template clauses based SAT techniques
CN112506806B (zh) 用于调试程序的方法、电子设备及存储介质
Copty et al. Efficient debugging in a formal verification environment
CN114490327A (zh) 一种错误检测方法及装置
Kaestner et al. Model-driven code generation and analysis
Jansen et al. The COMICS tool-Computing minimal counterexamples for discrete-time Markov chains
CN111224985B (zh) 通信协议可信性验证方法
US11507719B1 (en) Accelerating formal property verification across design versions using sequential equivalence checking

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant