CN110865899A - 一种基于llvm的内存泄露的静态检测方法及系统 - Google Patents

一种基于llvm的内存泄露的静态检测方法及系统 Download PDF

Info

Publication number
CN110865899A
CN110865899A CN201910993650.3A CN201910993650A CN110865899A CN 110865899 A CN110865899 A CN 110865899A CN 201910993650 A CN201910993650 A CN 201910993650A CN 110865899 A CN110865899 A CN 110865899A
Authority
CN
China
Prior art keywords
array
variable
information
variables
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.)
Granted
Application number
CN201910993650.3A
Other languages
English (en)
Other versions
CN110865899B (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.)
Beijing HJIMI Technology Co Ltd
Original Assignee
Beijing HJIMI 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 Beijing HJIMI Technology Co Ltd filed Critical Beijing HJIMI Technology Co Ltd
Priority to CN201910993650.3A priority Critical patent/CN110865899B/zh
Publication of CN110865899A publication Critical patent/CN110865899A/zh
Application granted granted Critical
Publication of CN110865899B publication Critical patent/CN110865899B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/073—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a memory management context, e.g. virtual memory or cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Devices For Executing Special Programs (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明公开了一种基于LLVM的内存泄露的静态检测方法及系统，利用C++堆分配指令信息，并在程序退出的时候，通过变量的活跃信息来判断可能的内存溢出的情况，能够在运行程序前发现那些浅显的表层的内存泄露的地方，减少以后程序修改迭代的次数；利用LLVM的框架模块化的特性，使用它成熟稳定的代码接口，技术方案简洁直接，不仅在静态编译的过程中能更早的发现内存泄露的地方，并且保证了代码实现的简单性，同时也使得结果更容易被测试。

Description

一种基于LLVM的内存泄露的静态检测方法及系统
技术领域
本发明涉及信息处理，尤其是一种基于LLVM的内存泄露的静态检测方法及系统。
背景技术
在C++语法中，内存分配只会在栈(stack)中或者在堆(heap)中。栈中的变量的分配和释放是由系统管理的，无需人工管理；但是堆中分配的变量，是由程序员自己维护的，需要程序员自己释放，如果忘了释放在堆中分配的空间，系统新的变量就会一直申请不到这个空间，就会造成内存泄露了。内存泄露包括在函数中跨函数的变量内存泄露等比较复杂的情况，也包括一部分内存泄露情况较为简单的情况。
现有的静态内存泄露的检测方法，其过程都非常复杂，而且中间代码生成都需要自己实现，整个过程调试也更加繁琐。解决内存泄露问题的方法有两种，一种是通过人工反复通读代码，检查是否有遗忘的未释放的变量；另一种是程序运行的时候查看内存是否一直在增加来判断是否有内存泄露，即使判断存在内存泄露，也无法快速确定内存泄露的地点，最终还是要回到第一种方法。但在代码量较大的情况下，人工查找非常不便、费时费力。
发明内容
发明目的：针对上述现有技术存在的缺陷，本发明旨在提供一种基于LLVM的内存泄露的静态检测方法及系统。
技术方案：一种基于LLVM的内存泄露的静态检测方法，包括：
在LLVM编译器中初始化3个空的局部数组：第一数组、第二数组、第三数组；
遍历所有块，将所有运行路径存储到第一数组中；
遍历第一数组中的所有路径，经历每条路径时：
将所有动态内存分配首次分配的变量添加到第二数组中，并将堆中活跃变量信息的开始信息部分存储在该活跃变量的记录信息中；
若存在指向堆的变量释放函数，则从第二数组中删除该变量的记录信息；
当第二数组中的变量被重新赋值或赋值给其他变量时，更新第二数组中的记录信息；若发生内存泄露，将内存泄露变量的信息存储到第三数组中；
在每条路径经历结束时，遍历第二数组和第三数组，输出内存泄露变量的活跃信息，清空第二数组和第三数组。
进一步的，所述初始化3个空的局部数组具体是在LLVM编译器的第一预设函数中初始化。
进一步的，所述遍历所有块，将所有运行路径存储到第一数组，包括：
从第一预设函数的入口开始经历不同的块，经历到含有退出函数指令的块时，产生一条路径；
继续经历其他块，将产生的每条路径上的块的信息作为一个记录存储到第一数组。
进一步的，在所述初始化3个空的局部数组之前，还包括：
创建指令文件，在指令文件中创建并注册指令类，所述指令类继承自LLVM编译器框架中的第一预设类；
在所述遍历第一数组中的所有路径结束后，还包括：
将指令文件添加到编译文件中编译，生成库，加载该库，运行在相应中间文件中，得到输出信息。
进一步的，所述当第二数组中的变量被重新赋值或赋值给其他变量时更新第二数组中的记录信息，其中第二数组中的变量包含关联变量。
进一步的，所述当第二数组中的变量被重新赋值时，更新第二数组中的记录信息，包括以下三种情况：
1)如果这个变量没有关联变量，则在第二数组中添加这个变量的活跃信息的结束信息；将这个变量的记录信息拷贝到第三数组中；
如果变量是通过动态内存分配重新赋值的，修改第二数组这个变量的初始活跃信息为被现在赋值的信息，并清空变量的结束活跃信息。
如果变量不是通过动态内存分配重新赋值的，则从第二数组中删除这个变量的记录；
2)如果这个变量有关联变量，则将其中一个关联变量覆盖该变量在第二数组中的记录，并删除该关联变量的记录；
如果这个变量是通过动态内存分配重新赋值的，就再在第二数组中生成一条该变量活跃信息的新记录；
3)如果这个变量本身就是一个关联变量，则在第二数组中删除这个变量的信息；
如果变量是通过动态内存分配重新赋值的，就再在第二数组中生成一条该变量活跃信息的新记录。
进一步的，所述将所有动态内存分配首次分配的变量添加到第二数组中，包括：将所有使用LLVM中第二预设函数和第一运算符首次分配的变量添加到第二数组中；其中，第二预设函数为用于动态内存分配的函数，第一运算符为用于动态分配和撤销内存的运算符。
一种基于LLVM的内存泄露的静态检测系统，包括：
数组初始化单元，用于在LLVM编译器中初始化3个空的局部数组：第一数组、第二数组、第三数组；
运行路径获取单元，用于遍历所有块，将所有运行路径存储到第一数组中；
路径遍历单元，用于遍历第一数组中的所有路径，经历每条路径时：将所有动态内存分配首次分配的变量添加到第二数组中，并将堆中活跃变量信息的开始信息部分存储在该活跃变量的记录信息中；
变量释放记录单元，用于在发现指向堆的变量释放函数时，从第二数组中删除该变量的记录信息；
内存泄露记录单元，用于当第二数组中的变量被重新赋值或赋值给其他变量时，更新第二数组中的记录信息；当发生内存泄露时，将内存泄露变量的信息存储到第三数组中；
复位输出单元，用于在每条路径经历结束时，遍历第二数组和第三数组，输出内存泄露变量的活跃信息，清空第二数组和第三数组。
进一步的，所述运行路径获取单元包括：
路径生成子单元，用于从第一预设函数的入口开始经历不同的块，经历到含有退出函数指令的块时，产生一条路径；
路径存储子单元，用于将产生的每条路径上的块的信息作为一个记录存储到第一数组。
进一步的，还包括：
文件创建单元，用于创建指令文件，在指令文件中创建并注册指令类，所述指令类继承自LLVM编译器框架中的第一预设类；
编译运行单元，用于将指令文件添加到编译文件中编译，生成库，加载该库，运行在相应中间文件中，得到输出信息。
有益效果：本发明提供了一种基于LLVM的内存泄露的静态检测方法及系统，利用C++堆分配指令信息，并在程序退出的时候，通过变量的活跃信息来判断可能的内存溢出的情况，能够在运行程序前发现那些浅显的表层的内存泄露的地方，减少以后程序修改迭代的次数；利用LLVM的框架模块化的特性，使用它成熟稳定的代码接口，技术方案简洁直接，不仅在静态编译的过程中能更早的发现内存泄露的地方，并且保证了代码实现的简单性，同时也使得结果更容易被测试。
附图说明
图1是本发明实施例的流程图。
具体实施方式
下面通过附图结合实施例对本技术方案进行详细说明。
LLVM作为编译器框架，分为前端，中间层和后端。前端主要有词法分析，语法分析，语义分析和生成中间代码这几个模块。中间层(IR)主要就是说的前端生成的中间代码，这里会做很多平台无关的优化。LLVM可以通过clang(是一个C语言、C++、Objective-C语言的轻量级编译器)可执行程序直接生成代码的IR文件。后端主要有创建SelectionDAG,指令选择，指令调度，寄存器分配和指令发射这几个模块。按照我们的功能需求，可以直接放在中间层的优化中。
LLVM编译器框架最大的一个优点就是模块化，它将编译器的各个阶段细分，最大程度的独立出来，并且提供了很多可嵌入自定义代码的地方。比如可以通过添加自定义优化类来加入自定义的编译优化功能。因此，我们实现一个C++类MemLeakSolver，继承自LLVM中的FunctionPass类，然后我们只需要专注实现runOnFunction这个函数，其中具体的实现就会在程序中的所有函数中都会运行到。最后编译生成lib库，通过opt可执行文件加载这个lib库，运行在对应的中间文件中，就可以得到打印的结果了。
在C++语法中，在堆中分配空间如果使用完了以后一直没有释放，就会造成内存泄露。如果一个变量的值在将来还需要使用，则称这个变量是活跃的。在LLVM框架中已经把程序划分成了多个module，module一般是以文件来划分的，模块下是多个function(也就是函数)，function中又分为多个block，block下面就是多个指令了。其中在block中只有一个入口和一个出口。我们只要实现类FunctionPass的runOnFunction的函数，就会依次在程序的所有的函数过程中被调用。本发明为了力求简单实用，所以结果只能显示内存泄露的一部分的情况，如果是在函数中跨函数的变量的内存泄露等比较复杂的情况就不能发现了。实现方法如下：
一种基于LLVM的内存泄露的静态检测方法，包括：
(1)创建指令文件，在指令文件中创建并注册指令类，所述指令类继承自LLVM编译器框架中的第一预设类；
本实施例中创建MemLeakSolver.cpp文件，在文件中创建MemLeakSolver类，继承自类FunctionPass，并注册这个类。
(2)在LLVM编译器的第一预设函数中初始化3个空的局部数组：第一数组、第二数组、第三数组；
本实施例在在函数runOnFunction中初始化3个空的局部数组，为：
第一数组：用于存储可能的运行路径数组pRunPathList；
第二数组：用于存储堆中分配的活跃变量的数组pHeapVarAry；
第三数组：用于存储已经存在内存泄露的变量数组pLeakVarAry；
(3)遍历所有块(即block)，将所有运行路径存储到第一数组中；包括：
从第一预设函数的入口开始经历不同的块，经历到含有退出函数指令的块时，产生一条路径；
继续经历其他块，将产生的每条路径上的块的信息作为一个记录存储到第一数组。
本实施例在函数runOnFunction中遍历所有block，将所有可能的运行路径保存到数组pRunPathList中去。具体来说，从函数入口开始，经历若干个block，最后遇到一个有退出函数的指令的block产生一条路径，经历不同的block，产生不同的路径，我们需要将这条路径上的block的信息作为一个记录存到pRunPathList变量中去，然后再继续迭代，直到所有路径的信息都被保存到pRunPathList中为止。
(4)遍历第一数组中的所有路径，经历每条路径时：
将所有动态内存分配首次分配的变量添加到第二数组中，即包括：将所有使用LLVM中第二预设函数和第一运算符首次分配的变量添加到第二数组中；其中，第二预设函数为用于动态内存分配的函数，第一运算符为用于动态分配和撤销内存的运算符。
并且，将堆中活跃变量信息的开始信息部分存储在该活跃变量的记录信息中；
本实施例遍历pRunPathList中的每一条路径，然后将所有使用第二预设函数malloc和第一运算符new首次分配的变量添加到数组pHeapVarAry中，并将堆中活跃变量信息的开始信息部分保存在这个变量的记录信息中。
若存在指向堆的变量释放函数，则从第二数组中删除该变量的记录信息；
本实施例中如果发现指向堆的变量释放函数free或delete，就会从pHeapVarAry中删除相关信息。
当第二数组中的变量被重新赋值或赋值给其他变量时，更新第二数组中的记录信息；若发生内存泄露，将内存泄露变量的信息存储到第三数组中；
其中第二数组中的变量包含关联变量。
本实施例中如果有pHeapVarAry中的变量(包括关联变量)被重新赋值，或赋值给其他变量，就需要修改pHeapVarAry中的信息，如果发生内存泄露，就将它的信息保存到pLeakVarAry数组中。
具体包括以下三种情况：
1)如果这个变量没有关联变量，则在第二数组中添加这个变量的活跃信息的结束信息；将这个变量的记录信息拷贝到第三数组中；
如果变量是通过动态内存分配重新赋值的，修改第二数组这个变量的初始活跃信息为被现在赋值的信息，并清空变量的结束活跃信息。
如果变量不是通过动态内存分配重新赋值的，则从第二数组中删除这个变量的记录；
2)如果这个变量有关联变量，则将其中一个关联变量覆盖该变量在第二数组中的记录，并删除该关联变量的记录；
如果这个变量是通过动态内存分配重新赋值的，就再在第二数组中生成一条该变量活跃信息的新记录；
3)如果这个变量本身就是一个关联变量，则在第二数组中删除这个变量的信息；
如果变量是通过动态内存分配重新赋值的，就再在第二数组中生成一条该变量活跃信息的新记录。
在每条路径经历结束时，遍历第二数组和第三数组，输出内存泄露变量的活跃信息，清空第二数组和第三数组。
在一条路径结束的时候，那么pHeapVarAry和pLeakVarAry数组中存在信息就可能已经被泄露了，所以本实施例遍历这2个数组，打印内存泄露变量相关的活跃信息，然后清空这2个数组，继续遍历其他的路径，直到所有路径被遍历完为止。
将指令文件添加到编译文件中编译，生成库，加载该库，运行在相应中间文件中，得到输出信息。
本实施例中将MemLeakSolver.cpp文件添加到CMakeLists.txt中，并编译生成lib库。通过opt加载这个库，运行在相应的中间文件中，得到打印信息，即输出信息。
一种使用上述方法的基于LLVM的内存泄露的静态检测系统，包括：文件创建单元、数组初始化单元、运行路径获取单元、路径遍历单元、变量释放记录单元、内存泄露记录单元、复位输出单元、编译运行单元。
文件创建单元，用于创建指令文件，在指令文件中创建并注册指令类，所述指令类继承自LLVM编译器框架中的第一预设类。
数组初始化单元，用于在LLVM编译器中初始化3个空的局部数组：第一数组、第二数组、第三数组。
运行路径获取单元，用于遍历所有块，将所有运行路径存储到第一数组中，包括：
路径生成子单元，用于从第一预设函数的入口开始经历不同的块，经历到含有退出函数指令的块时，产生一条路径；
路径存储子单元，用于将产生的每条路径上的块的信息作为一个记录存储到第一数组。
路径遍历单元，用于遍历第一数组中的所有路径，经历每条路径时：将所有动态内存分配首次分配的变量添加到第二数组中，并将堆中活跃变量信息的开始信息部分存储在该活跃变量的记录信息中。
变量释放记录单元，用于在发现指向堆的变量释放函数时，从第二数组中删除该变量的记录信息。
内存泄露记录单元，用于当第二数组中的变量被重新赋值或赋值给其他变量时，更新第二数组中的记录信息；当发生内存泄露时，将内存泄露变量的信息存储到第三数组中。
复位输出单元，用于在每条路径经历结束时，遍历第二数组和第三数组，输出内存泄露变量的活跃信息，清空第二数组和第三数组。
编译运行单元，用于将指令文件添加到编译文件中编译，生成库，加载该库，运行在相应中间文件中，得到输出信息。
本实施例中该系统运行时，各单元配合实现上述基于LLVM的内存泄露的静态检测方法的所有技术方案，采用的实现方法与其一致。
以下结合图1，具体描述实现的详细情况：
步骤101：创建MemLeakSolver.cpp文件，在文件中创建MemLeakSolver类，继承自类FunctionPass。
并使用RegisterPass来注册这个类。
步骤102：现在要开始实现函数runOnFunction了，先初始化3个空的局部数组，一个是堆中分配的活跃变量的数组pHeapVarAry，一个是已经存在内存泄露的变量数组pLeakVarAry，和可能的运行路径数组pRunPathList。
步骤103：在函数runOnFunction中遍历所有block，将所有可能的运行路径保存到数组pRunPathList中去。具体来说，从函数入口开始，经历若干个block，最后遇到一个有退出函数的指令的block产生一条路径，经历不同的block，产生不同的路径，我们需要将这条路径上的block的信息作为一个记录存到pRunPathList变量中去，然后再继续迭代，直到所有路径的信息都被保存到pRunPathList中为止。
路径分支的产生主要有以下几种常见情况：
1)如果函数中有判断语句if，就会产生判断为真和为假的两条路径分支(其中假的路径可能是空操作)，为真和为假所需要执行的代码，会被分在不同的的block中。
2)如果是while循环，会有条件判断和循环主体2个block，和if类似。
3)如果是for循环，就会有条件判断，循环主体和自增部分3个部分，条件判断是肯定会执行的，循环主体和自增部分是一起的，也就是要不一起执行，要不都不执行，所以也分成两条路径分支。
4)如果是do-while循环，也会产生循环主体和条件判断2个block，但是由于都会被至少执行一次，所以不会产生额外的路径，总的来说，对于循环，路径选择只在乎block有没有被执行，不关心block执行的次数。
步骤104：遍历pRunPathList中的每一条路径，循环获取这条路径上的每个block的信息，然后分析这个block中的所有指令，最后将所有使用函数malloc和new首次分配的变量添加到数组pHeapVarAry中，并将堆中活跃变量信息的开始信息部分保存在这个变量的记录信息中。
步骤105：如果发现指向堆的变量释放函数free和delete，就会从pHeapVarAry中删除这个变量的信息，包括其主变量或关联变量的信息。
步骤106：如果有pHeapVarAry中的变量A被分配给了其他变量B，就将变量B加入到变量A的关联变量，并添加B的活跃信息。同理，后面又将变量B分配给了变量C，同样也将C关联到变量A，并添加C的活跃信息。对于pHeapVarAry中的变量被重新赋值，就要分三种情况：
1)如果这个变量没有关联变量，就需要在pHeapVarAry中添加这个变量的活跃信息的结束信息。然后将这个变量的记录信息拷贝到pLeakVarAry数组中去。如果变量是通过malloc或new函数重新赋值的，就修改pHeapVarAry这个变量的初始活跃信息为被现在赋值的信息，并清空变量的结束活跃信息。如果变量不是通过malloc或new函数重新赋值的，就从pHeapVarAry中删除这条记录。
2)如果这个变量有关联变量，就将它的其中一个关联变量覆盖它，并删除这个关联变量的记录。如果变量是通过malloc或new函数重新赋值的，就再在pHeapVarAry中生成一条该变量活跃信息的新记录。
3)如果这个变量本身就是一个关联变量，可以直接在pHeapVarAry中删除这个变量的信息，同理，如果变量是通过malloc或new函数重新赋值的，就再在pHeapVarAry中生成一条该变量活跃信息的新记录。
其中，以上步骤104、105、106的顺序、位置不限，只要实现相应功能即可。
步骤107：在一条路径结束的时候，那么pHeapVarAry和pLeakVarAry数组中存在信息就已经是内存泄露的了，所以遍历这2个数组，打印内存泄露变量相关的信息，然后清空这2个数组，继续遍历步骤104、105、106、107直到所有路径都遍历完为止。
步骤108：最后将MemLeakSolver.cpp文件添加到CMakeLists.txt中，并编译生成lib库。通过opt加载这个库，运行在相应的中间文件中，得到打印的内存泄露的信息。
以上仅是本发明的优选实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种基于LLVM的内存泄露的静态检测方法，其特征在于，包括：
在LLVM编译器中初始化3个空的局部数组：第一数组、第二数组、第三数组；
遍历所有块，将所有运行路径存储到第一数组中；
遍历第一数组中的所有路径，经历每条路径时：
将所有动态内存分配首次分配的变量添加到第二数组中，并将堆中活跃变量信息的开始信息部分存储在该活跃变量的记录信息中；
若存在指向堆的变量释放函数，则从第二数组中删除该变量的记录信息；
当第二数组中的变量被重新赋值或赋值给其他变量时，更新第二数组中的记录信息；若发生内存泄露，将内存泄露变量的信息存储到第三数组中；
在每条路径经历结束时，遍历第二数组和第三数组，输出内存泄露变量的活跃信息，清空第二数组和第三数组。
2.根据权利要求1所述的一种基于LLVM的内存泄露的静态检测方法，其特征在于，所述初始化3个空的局部数组具体是在LLVM编译器的第一预设函数中初始化。
3.根据权利要求2所述的一种基于LLVM的内存泄露的静态检测方法，其特征在于，所述遍历所有块，将所有运行路径存储到第一数组，包括：
从第一预设函数的入口开始经历不同的块，经历到含有退出函数指令的块时，产生一条路径；
继续经历其他块，将产生的每条路径上的块的信息作为一个记录存储到第一数组。
4.根据权利要求1所述的一种基于LLVM的内存泄露的静态检测方法，其特征在于，在所述初始化3个空的局部数组之前，还包括：
创建指令文件，在指令文件中创建并注册指令类，所述指令类继承自LLVM编译器框架中的第一预设类；
在所述遍历第一数组中的所有路径结束后，还包括：
将指令文件添加到编译文件中编译，生成库，加载该库，运行在相应中间文件中，得到输出信息。
5.根据权利要求1所述的一种基于LLVM的内存泄露的静态检测方法，其特征在于，所述当第二数组中的变量被重新赋值或赋值给其他变量时更新第二数组中的记录信息，其中第二数组中的变量包含关联变量。
6.根据权利要求5所述的一种基于LLVM的内存泄露的静态检测方法，其特征在于，所述当第二数组中的变量被重新赋值时，更新第二数组中的记录信息，包括以下三种情况：
1)如果这个变量没有关联变量，则在第二数组中添加这个变量的活跃信息的结束信息；将这个变量的记录信息拷贝到第三数组中；
如果变量是通过动态内存分配重新赋值的，修改第二数组这个变量的初始活跃信息为被现在赋值的信息，并清空变量的结束活跃信息。
如果变量不是通过动态内存分配重新赋值的，则从第二数组中删除这个变量的记录；
2)如果这个变量有关联变量，则将其中一个关联变量覆盖该变量在第二数组中的记录，并删除该关联变量的记录；
如果这个变量是通过动态内存分配重新赋值的，就再在第二数组中生成一条该变量活跃信息的新记录；
3)如果这个变量本身就是一个关联变量，则在第二数组中删除这个变量的信息；
如果变量是通过动态内存分配重新赋值的，就再在第二数组中生成一条该变量活跃信息的新记录。
7.根据权利要求1所述的一种基于LLVM的内存泄露的静态检测方法，其特征在于，所述将所有动态内存分配首次分配的变量添加到第二数组中，包括：将所有使用LLVM中第二预设函数和第一运算符首次分配的变量添加到第二数组中；其中，第二预设函数为用于动态内存分配的函数，第一运算符为用于动态分配和撤销内存的运算符。
8.一种基于LLVM的内存泄露的静态检测系统，其特征在于，包括：
数组初始化单元，用于在LLVM编译器中初始化3个空的局部数组：第一数组、第二数组、第三数组；
运行路径获取单元，用于遍历所有块，将所有运行路径存储到第一数组中；
路径遍历单元，用于遍历第一数组中的所有路径，经历每条路径时：将所有动态内存分配首次分配的变量添加到第二数组中，并将堆中活跃变量信息的开始信息部分存储在该活跃变量的记录信息中；
变量释放记录单元，用于在发现指向堆的变量释放函数时，从第二数组中删除该变量的记录信息；
内存泄露记录单元，用于当第二数组中的变量被重新赋值或赋值给其他变量时，更新第二数组中的记录信息；当发生内存泄露时，将内存泄露变量的信息存储到第三数组中；
复位输出单元，用于在每条路径经历结束时，遍历第二数组和第三数组，输出内存泄露变量的活跃信息，清空第二数组和第三数组。
9.根据权利要求8所述的一种基于LLVM的内存泄露的静态检测系统，其特征在于，所述运行路径获取单元包括：
路径生成子单元，用于从第一预设函数的入口开始经历不同的块，经历到含有退出函数指令的块时，产生一条路径；
路径存储子单元，用于将产生的每条路径上的块的信息作为一个记录存储到第一数组。
10.根据权利要求8所述的一种基于LLVM的内存泄露的静态检测系统，其特征在于，还包括：
文件创建单元，用于创建指令文件，在指令文件中创建并注册指令类，所述指令类继承自LLVM编译器框架中的第一预设类；
编译运行单元，用于将指令文件添加到编译文件中编译，生成库，加载该库，运行在相应中间文件中，得到输出信息。
CN201910993650.3A 2019-10-18 2019-10-18 一种基于llvm的内存泄露的静态检测方法及系统 Active CN110865899B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910993650.3A CN110865899B (zh) 2019-10-18 2019-10-18 一种基于llvm的内存泄露的静态检测方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910993650.3A CN110865899B (zh) 2019-10-18 2019-10-18 一种基于llvm的内存泄露的静态检测方法及系统

Publications (2)

Publication Number Publication Date
CN110865899A true CN110865899A (zh) 2020-03-06
CN110865899B CN110865899B (zh) 2023-09-05

Family

ID=69652434

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910993650.3A Active CN110865899B (zh) 2019-10-18 2019-10-18 一种基于llvm的内存泄露的静态检测方法及系统

Country Status (1)

Country Link
CN (1) CN110865899B (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104461890A (zh) * 2014-12-12 2015-03-25 四川川大智胜软件股份有限公司 一种航管训练系统开发中Qt程序内存使用静态检查方法
CN104750563A (zh) * 2013-12-26 2015-07-01 北京大学 一种基于控制流图的内存泄漏自动修复方法
CN105224864A (zh) * 2015-11-04 2016-01-06 中国科学院计算技术研究所 一种抵御代码重用攻击的工作进程随机化方法及系统
US10089223B1 (en) * 2017-06-01 2018-10-02 International Business Machines Corporation Memory categorization

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104750563A (zh) * 2013-12-26 2015-07-01 北京大学 一种基于控制流图的内存泄漏自动修复方法
CN104461890A (zh) * 2014-12-12 2015-03-25 四川川大智胜软件股份有限公司 一种航管训练系统开发中Qt程序内存使用静态检查方法
CN105224864A (zh) * 2015-11-04 2016-01-06 中国科学院计算技术研究所 一种抵御代码重用攻击的工作进程随机化方法及系统
US10089223B1 (en) * 2017-06-01 2018-10-02 International Business Machines Corporation Memory categorization

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KANGJIE LU ET AL: "UniSan: Proactive Kernel Memory Initialization to Eliminate Data Leakages", 《CCS’16》 *
朱玲等: "C程序精确形状分析中的规范语言设计", 《小型微型计算机系统》 *
杨克等: "精准执行可达性分析:理论与应用", 《软件学报》 *

Also Published As

Publication number Publication date
CN110865899B (zh) 2023-09-05

Similar Documents

Publication Publication Date Title
Ho et al. An approach to genuine dynamic linking
Wimmer et al. Linear scan register allocation on SSA form
JP3553834B2 (ja) コンピュータアーキテクチャエミュレーションシステム
KR101354796B1 (ko) 소프트웨어 트랜잭션 메모리 블록들을 포함하는 프로그램의컴파일을 위한 방법
US8645933B2 (en) Method and apparatus for detection and optimization of presumably parallel program regions
US6077311A (en) Method and apparatus for extraction of program region
Lee et al. Reconciling high-level optimizations and low-level code in LLVM
Diaz et al. On the implementation of GNU Prolog
Li et al. Detecting cross-language memory management issues in rust
Moses et al. High-performance gpu-to-cpu transpilation and optimization via high-level parallel constructs
Bockisch et al. Efficient control flow quantification
Brandis et al. The Oberon system family
CN110865899A (zh) 一种基于llvm的内存泄露的静态检测方法及系统
Hallahan et al. G2Q: Haskell constraint solving
Hammacher Design and implementation of an efficient dynamic slicer for Java
Crary et al. Type structure for low-level programming languages
Alt et al. TrafoLa-H subsystem
Kraus et al. The swift language from a reverse engineering perspective
Wimmer Linear scan register allocation for the Java HotSpotTM client compiler
Schilling Challenges for a trace-based just-in-time compiler for Haskell
Somogyi et al. Status of the Mercury system
Chen et al. Lessons Learned Migrating CUDA to SYCL: A HEP Case Study with ROOT RDataFrame
Artho et al. Subroutine inlining and bytecode abstraction to simplify static and dynamic analysis
Wimmer Automatic object inlining in a Java virtual machine
Melançon Reusable semantics for implementation of Python optimizing compilers

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