CN113157513A - 一种堆内存破坏检测方法、装置、电子设备及存储介质 - Google Patents
一种堆内存破坏检测方法、装置、电子设备及存储介质 Download PDFInfo
- Publication number
- CN113157513A CN113157513A CN202110504336.1A CN202110504336A CN113157513A CN 113157513 A CN113157513 A CN 113157513A CN 202110504336 A CN202110504336 A CN 202110504336A CN 113157513 A CN113157513 A CN 113157513A
- Authority
- CN
- China
- Prior art keywords
- memory
- heap
- corruption
- heap memory
- memory block
- 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.)
- Pending
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 87
- 230000009225 memory damage Effects 0.000 title claims abstract description 52
- 230000006870 function Effects 0.000 claims abstract description 163
- 230000006378 damage Effects 0.000 claims description 62
- 238000000034 method Methods 0.000 claims description 35
- 230000002457 bidirectional effect Effects 0.000 claims description 16
- 238000012544 monitoring process Methods 0.000 claims description 13
- 230000008569 process Effects 0.000 description 9
- 239000011664 nicotinic acid Substances 0.000 description 8
- 238000010586 diagram Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000010076 replication Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000010998 test method Methods 0.000 description 1
- 238000004804 winding Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2205—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2273—Test methods
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Techniques For Improving Reliability Of Storages (AREA)
Abstract
本公开实施例涉及计算机技术领域，具体涉及一种堆内存破坏检测方法、装置、电子设备及存储介质。本公开的至少一个实施例中，基于操作系统提供的第一堆内存破坏接口携带的发生堆内存破坏的函数信息，确定堆内存破坏类型，进而可基于不同的堆内存破坏类型采用不同的堆内存破坏检测方式排查内存，确定发生堆内存破坏的第一内存块，从而获取与第一内存块相邻的第二内存块的相关信息以及第一内存块的相关信息，从而输出第一内存块的相关信息和第二内存块的相关信息，便于确定发生堆内存破坏的原因和堆内存破坏的位置等信息。可见，在每次发生堆内存破坏后，可以输出更多的堆内存破坏相关信息，便于动态检测发生破坏的内存块，提高检测效率。
Description
技术领域
本公开实施例涉及计算机技术领域，具体涉及一种堆内存破坏检测方法、装置、电子设备及存储介质。
背景技术
堆内存是区别于栈区、全局数据区和代码区的另一个内存区域。堆内存由内存管理器进行分配和释放，不同的内存管理器具有不同的内存管理逻辑，内存管理逻辑包括排查堆内存破坏的逻辑。
造成堆内存破坏的原因有多种，例如数组越界、强制转换到一个错误的类型、未初始化的指针、缺少或者不完整的拷贝构造、指向已回收内存的指针、重复释放同一块内存、多重基类但是没有虚析构函数等原因。
目前，堆内存破坏检测方案一般通过获取coredump(内核转存)文件来静态分析发生破坏的内存块。然而，由于操作系统的权限管控，程序通常难以获取coredump文件。另外，coredump文件比较大，对磁盘和流量损耗都比较大。因此，亟需提供一种堆内存破坏检测方案，实现动态检测发生破坏的内存块，提高检测效率。
发明内容
为了解决现有技术存在的至少一个问题，本公开的至少一个实施例提供了一种堆内存破坏检测方法、装置、电子设备及存储介质。
第一方面，本公开实施例提出一种堆内存破坏检测方法，所述方法包括：
基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息，确定堆内存破坏类型；
基于堆内存破坏类型，确定发生堆内存破坏的第一内存块，并获取与第一内存块相邻的第二内存块的相关信息以及第一内存块的相关信息；
输出第一内存块的相关信息和第二内存块的相关信息。
在一些实施例中，堆内存破坏类型包括第一类型和第二类型；
第一类型包括存储容量小于256字节的内存块，第二类型包括存储容量大于或等于256字节的内存块。
在一些实施例中，基于堆内存破坏类型，确定发生堆内存破坏的第一内存块包括：
基于堆内存破坏类型为第一类型，以双向链表管理逻辑排查内存，得到发生堆内存破坏的第一内存块；
基于堆内存破坏类型为第二类型，以树管理逻辑和双向链表管理逻辑排查内存，得到发生堆内存破坏的第一内存块。
在一些实施例中，以双向链表管理逻辑排查内存之前，方法还包括：
解析预先加载的标准库，获取用于记录堆内存的管理数据的全局变量地址；
基于全局变量地址，确定全局变量中用于记录双向链表的数组；
遍历数组，确定至少一个双向链表的入口；
相应地，以双向链表管理逻辑排查内存包括：
基于至少一个双向链表的入口，以双向链表管理逻辑排查内存。
在一些实施例中，以树管理逻辑和双向链表管理逻辑排查内存包括：
对树中各节点以树管理逻辑进行排查；
在以树管理逻辑进行排查后，对树中以双向链表管理的节点以双向链表管理逻辑进行排查。
在一些实施例中，第二内存块的相关信息包括以下至少一种：第二内存块本身的信息、与第二内存块相邻的内存块本身的信息和第二内存块上存储的应用数据。
在一些实施例中，确定堆内存破坏类型前，方法还包括：
监控第一堆内存破坏接口；
在监控到调用第一堆内存破坏接口后，调用第二堆内存破坏接口；
在调用第二堆内存破坏接口后，执行确定堆内存破坏类型；
确定堆内存破坏信息后，方法还包括：
返回第一堆内存破坏接口对应的函数，以执行第一堆内存破坏接口对应的函数。
第二方面，本公开实施例还提出一种堆内存破坏检测装置，所述装置包括：
确定单元，用于基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息，确定堆内存破坏类型；
获取单元，用于基于堆内存破坏类型，确定发生堆内存破坏的第一内存块，并获取与第一内存块相邻的第二内存块的相关信息以及第一内存块的相关信息；
输出单元，用于输出第一内存块的相关信息和第二内存块的相关信息。
第三方面，本公开实施例还提供一种电子设备，包括：处理器和存储器；所述处理器通过调用所述存储器存储的程序或指令，用于执行第一方面任一项所述方法的步骤。
第四方面，本公开实施例还提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行第一方面任一项所述方法的步骤。
可见，本公开的至少一个实施例中，基于操作系统提供的第一堆内存破坏接口携带的发生堆内存破坏的函数信息，确定堆内存破坏类型，进而可基于不同的堆内存破坏类型采用不同的堆内存破坏检测方式排查内存，确定发生堆内存破坏的第一内存块，从而获取与第一内存块相邻的第二内存块的相关信息以及第一内存块的相关信息，从而输出第一内存块的相关信息和第二内存块的相关信息，便于确定发生堆内存破坏的原因和堆内存破坏的位置(内存头部被破坏，还是内存尾部被破坏)等信息。可见，在每次发生堆内存破坏后，可以输出更多的堆内存破坏相关信息，便于动态检测发生破坏的内存块，提高检测效率。
附图说明
为了更清楚地说明本公开实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1是本公开实施例提供的一种堆内存破坏检测方法的示例性流程图；
图2是本公开实施例提供的一种应用场景下进行堆内存破坏检测的流程图；
图3是本公开实施例提供的一种堆内存破坏检测装置的示例性框图；
图4是本公开实施例提供的一种电子设备的示例性框图。
具体实施方式
为了能够更清楚地理解本公开的上述目的、特征和优点，下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，所描述的实施例是本公开的一部分实施例，而不是全部的实施例。此处所描述的具体实施例仅仅用于解释本公开，而非对本公开的限定。基于所描述的本公开的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本公开保护的范围。
需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
coredump(内核转存)文件是操作系统在程序出错而异常中断时，将程序当前的工作状态存储成的文件。coredump文件包括程序运行时的内存，寄存器状态，堆栈指针，内存管理信息等。由于操作系统的权限管控，程序通常难以获取coredump文件。另外，coredump文件比较大，对磁盘和流量损耗都比较大。因此，亟需提供一种堆内存破坏检测方案，实现动态检测发生破坏的内存块，提高检测效率。
每个内存管理器有各自的内存管理逻辑，因此，在分配内存的过程中，不同内存管理器基于各自的内存管理逻辑对堆内存进行不同管理。例如，对于dlmalloc这种内存管理器，管理数据和应用数据放在一起；对于安卓某些版本的内存管理器，管理数据和应用数据不放在一起。其中，应用数据可理解为与程序(APP)相关的数据，例如由程序所发生的数据。管理数据可以理解为非应用数据。在一些实施例中，管理数据可包括内存块的状态、容量(Size)等内存块本身的信息。其中，内存块的状态为使用中(in used)或空闲(free)。在一些实施例中，管理数据还可包括相邻内存块的状态、容量等相邻内存块本身的信息。
例如，对于dlmalloc，管理数据占用0.5兆内存容量，程序申请容量为1兆的内存块，则dlmalloc实际分配的内存块并非1兆，而是1.5兆，这1.5兆即为内存块的容量(Size)，且这1.5兆的内存块按内存地址由小至大，前0.5兆存放管理数据，后1兆存放应用数据。需要说明的是，管理数据所占用的容量为固定容量，以固定容量为0.5兆举例，若程序申请2兆的内存块，则dlmalloc实际分配的内存块是2.5兆，前0.5兆存放管理数据。这样，管理数据和应用数据就放在一起了(即放在同一内存块中)。当出现内存非法访问或其他原因时，可能导致堆内存的管理数据被破坏，发生堆内存破坏的问题。
在发生堆内存破坏时，不同内存管理器针对同一堆内存破坏，采用不同的内存管理逻辑(算法)来排查内存状态和/或管理数据。例如，发生堆内存破坏后，对于内存管理器A，需要基于内存管理器A的内存管理逻辑来排查内存状态和/或管理数据，进而获取堆内存破坏的信息；对于内存管理器B，需要基于内存管理器B的内存管理逻辑来排查内存状态和/或管理数据，进而获取堆内存破坏的信息。
不同的操作系统可能提供不同的堆内存破坏接口，堆内存破坏接口为操作系统在发生堆内存破坏后所调用的接口。堆内存破坏接口可以理解为堆内存破坏函数的函数名，调用堆内存破坏接口即为调用堆内存破坏函数。操作系统调用堆内存破坏接口后，基于堆内存破坏函数的逻辑进行处理，该处理例如输出堆内存破坏日志信息，并退出程序。
对于安卓(Android)系统，Android系统的C标准库(Libc)中提供了堆内存破坏接口：_bionic_heap_corruption_error。堆内存破坏函数的具体定义如下：
其中，堆内存破坏函数的参数为function，这个function可以理解为发生堆内存破坏的函数。另外，堆内存破坏函数中的_libc_fatal(“heap corruption detected by％s”，function)即为输出堆内存破坏日志信息。
当发生堆内存破坏后，Android系统调用堆内存破坏接口：_bionic_heap_corruption_error，进而输出堆内存破坏日志信息：“heap corruption detected byfunction”，并退出程序。可见，基于该堆内存破坏日志信息仅可知道发生了堆内存破坏，且发生堆内存破坏的函数为function。
然而，堆内存破坏日志信息所包含的堆内存破坏内容较少，仅知道发生了堆内存破坏，不足以分析堆内存破坏信息(例如发生堆内存破坏的原因，堆内存破坏的位置等)。因此，本公开实施例提供了一种堆内存破坏检测方法、装置、电子设备及存储介质，基于操作系统提供的第一堆内存破坏接口携带的发生堆内存破坏的函数信息，确定堆内存破坏类型，进而可基于不同的堆内存破坏类型采用不同的堆内存破坏检测方式排查内存，确定发生堆内存破坏的第一内存块，从而获取与第一内存块相邻的第二内存块的相关信息以及第一内存块的相关信息，从而输出第一内存块的相关信息和第二内存块的相关信息，便于确定发生堆内存破坏的原因和堆内存破坏的位置(内存头部被破坏，还是内存尾部被破坏)等。可见，在每次发生堆内存破坏后，可以输出更多的堆内存破坏相关信息，便于动态检测发生破坏的内存块，提高检测效率。
实施例1，图1是本公开实施例提供的一种堆内存破坏检测方法的示例性流程图。在一些实施例中，该堆内存破坏检测方法的执行主体为程序(APP)。需要说明的是，内存管理器由操作系统提供，例如dlmalloc由Android系统提供。APP在运行时会将内存管理器加载到APP的进程空间，因此，APP对堆内存具有读和写的权限，也即APP可以访问堆内存。当发生堆内存破坏时，APP可以查找存放被破坏的管理数据的内存位置，进而获取内存块的相关数据和内存块上存储的应用数据，便于后续分析堆内存破坏的原因。
在一些实施例中，堆内存破坏检测方法的执行主体为安装有程序(APP)的电子设备。其中，电子设备可以为智能手机、笔记本电脑、平板电脑、台式计算机、智能电视、智能运动装备等具有操作系统的设备。为便于描述，实施例中以电子设备为执行主体描述堆内存破坏检测方法的流程。
如图1所示，在步骤101中，电子设备基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息，确定堆内存破坏类型。
其中，第一堆内存破坏接口为操作系统所提供的堆内存破坏接口。第一堆内存破坏接口为操作系统在发生堆内存破坏后所调用的接口。第一堆内存破坏接口可以理解为操作系统提供的堆内存破坏函数的函数名，调用第一堆内存破坏接口即为调用堆内存破坏函数。例如，Android系统的C标准库(Libc)中提供的第一堆内存破坏接口为：_bionic_heap_corruption_error。
本实施例中，由于第一堆内存破坏接口可以理解为堆内存破坏函数的函数名，因此，第一堆内存破坏接口携带的发生堆内存破坏的函数信息可以理解为堆内存破坏函数的参数信息。
例如，Android系统的C标准库中提供的第一堆内存破坏接口为：_bionic_heap_corruption_error，堆内存破坏函数的具体定义如下：
那么，堆内存破坏函数的参数为function，这个function为发生堆内存破坏的函数的函数名，也即function为发生堆内存破坏的函数信息。
在一些实施例中，以dlmalloc这种内存管理器为例，在dlmalloc分配内存的过程中，发生堆内存破坏的函数包括三种：dlmalloc_real，tmalloc_small，tmalloc_large。因此，堆内存破坏函数的参数“function”为dlmalloc_real、tmalloc_small或tmalloc_large。其中，dlmalloc_real用于在小于256字节的空闲内存块中寻找合适的内存块去分配；tmalloc_small和tmalloc_large用于在大于或等于256字节的空闲内存块中寻找合适的内存块去分配。
在一些实施例中，堆内存破坏类型包括第一类型和第二类型，其中，第一类型包括存储容量小于256字节的内存块，第二类型包括存储容量大于或等于256字节的内存块。
在一些实施例中，基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息(即function)为dlmalloc_real，则确定堆内存破坏类型为第一类型，也即小于256字节的内存块发生破坏。基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息(即function)为tmalloc_small或tmalloc_large，则确定堆内存破坏类型为第二类型，也即大于或等于256字节的内存块发生破坏。
在步骤102中，电子设备基于堆内存破坏类型，确定发生堆内存破坏的第一内存块，并获取与第一内存块相邻的第二内存块的相关信息以及第一内存块的相关信息。
其中，第二内存块的相关信息可包括第二内存块本身的信息，例如第二内存块的状态、第二内存块的容量(Size)等。其中，第二内存块的状态为使用中(in used)或空闲(free)。在一些实施例中，第二内存块的相关信息还可包括与第二内存块相邻的内存块本身的信息。在一些实施例中，第二内存块的相关信息还可包括第二内存块上存储的应用数据。
其中，第一内存块的相关信息可包括第一内存块本身的信息，例如第一内存块的状态、第一内存块的容量(Size)等。其中，第一内存块的状态为使用中(in used)或空闲(free)。在一些实施例中，第一内存块的相关信息还可包括第一内存块上存储的应用数据。
在步骤103中，电子设备输出第一内存块的相关信息和第二内存块的相关信息。
在每次发生堆内存破坏后，相比第一堆内存破坏接口输出堆内存破坏日志信息，仅知道发生了堆内存破坏，本实施例可以输出更多的堆内存破坏相关信息，包括：第一内存块的相关信息和第二内存块的相关信息，便于人工确定发生堆内存破坏的原因和堆内存破坏的位置(内存头部被破坏，还是内存尾部被破坏)等信息，便于动态检测发生破坏的内存块，提高检测效率。
实施例2，在一些实施例中，电子设备可基于堆内存破坏类型和内存管理器的内存管理逻辑对内存进行排查得到发生堆内存破坏的第一内存块。内存管理器为预先安装在电子设备中的内存管理器，且内存管理逻辑可预先获取到。需要说明的是，不同内存管理器的内存管理逻辑不同，因此，检查第一内存块的方式也不同。另外，同一内存管理器针对不同堆内存破坏类型，也具有不同的内存管理逻辑，因此，检查第一内存块的方式也不同。
在一些实施例中，电子设备基于堆内存破坏类型为第一类型，以双向链表管理逻辑排查内存，得到发生堆内存破坏的第一内存块。电子设备基于堆内存破坏类型为第二类型，以树管理逻辑和双向链表管理逻辑排查内存，得到发生堆内存破坏的第一内存块。
以dlmalloc这种内存管理器为例，dlmalloc按照内存块的大小，采用了两种内存管理方式，具体地，对于小于256字节的空闲内存块，采用双向链表的管理方式；大于或等于256字节的空闲内存块采用了树加链表的管理方式。
对于双向链表的管理方式，与第一内存块相邻的第二内存块包括两个：第一内存块的前驱节点和第一内存块的后继节点。其中，前驱节点和后继节点均为内存块。
对于树的管理方式，与第一内存块相邻的第二内存块包括两个：第一内存块的父节点和第一内存块的子节点。其中，父节点和子节点实质上均为内存块，一个父节点对应两个子节点，分别称为父节点的左节点和右节点。
在一些实施例中，基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息(即function)为dlmalloc_real，则确定堆内存破坏类型为第一类型，也即小于256字节的内存块发生破坏。相应地，dlmalloc这种内存管理器针对堆内存破坏类型为第一类型，内存管理逻辑为双向链表管理逻辑：对双向链表中第一内存块的相邻节点进行排查，双向链表管理逻辑确定具体包括：节点地址合法性排查和节点链表合法性排查。
节点地址合法性排查：检查节点地址是否大于或等于堆内存的最小地址，若是，则节点地址合法。
节点链表合法性排查：如节点A，节点B相邻，且节点A指向的下一个节点为节点B，则节点B指向的前一个节点必须是节点A，否则节点链表不合法，即节点B不合法，节点B对应的内存块发生了堆内存破坏。
在一些实施例中，基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息(即function)为tmalloc_small或tmalloc_large，则确定堆内存破坏类型为第二类型，也即大于或等于256字节的内存块发生破坏。相应地，dlmalloc这种内存管理器针对堆内存破坏类型为第二类型，内存管理逻辑为树管理逻辑和双向链表管理逻辑同时采用。
树管理逻辑包括节点地址合法性排查和节点树合法性排查。
节点地址合法性排查：检查节点地址是否大于或等于堆内存的最小地址，若是，则节点地址合法。
节点树合法性排查：父节点应当指向左节点和右节点，同时左节点和右节点也应当指向父节点，若父节点指向右节点，但右节点不指向父节点，则节点树不合法，即右节点不合法，右节点对应的内存块发生了堆内存破坏。
实施例3，在一些实施例中，电子设备以双向链表管理逻辑排查内存之前，解析预先加载的标准库，获取用于记录堆内存的管理数据的全局变量地址；基于所述全局变量地址，确定全局变量中用于记录双向链表的数组；遍历所述数组，确定至少一个双向链表的入口；进而基于至少一个双向链表的入口，以双向链表管理逻辑排查内存。
例如，dlmalloc这种内存管理器通过全局变量记录堆内存的管理数据，双向链表记录在_gm_变量的smallbins数组中。可通过解析libc库中的全局变量_gm_，获取全局变量_gm_的地址。在一些实施例中，由于libc库加载的较早，因此基于Linux系统ELF(Executable and Linkable Format，可执行与可链接格式)的格式解析libc库，获取_gm_的地址。
在获取_gm_的地址后，通过遍历_gm_变量的smallbins数组找到至少一个双向链表的入口，通过遍历这些双向链表的节点，基于内存管理器的双向链表管理逻辑排查内存，确定链表节点是否被破坏。当发现被破坏的内存块后，将相邻内存块的相关信息进行读取，以获取相邻内存块的相关信息。
实施例4，在一些实施例中，电子设备基于堆内存破坏类型为第二类型，以树管理逻辑和双向链表管理逻辑排查内存包括：对树中各节点以树管理逻辑进行排查；在以树管理逻辑进行排查后，对树中以双向链表管理的节点以双向链表管理逻辑进行排查。
例如，基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息(即function)为tmalloc_small或tmalloc_large，则确定堆内存破坏类型为第二类型，也即大于或等于256字节的内存块发生破坏。相应地，dlmalloc这种内存管理器针对堆内存破坏类型为第二类型，内存管理逻辑为树管理逻辑和双向链表管理逻辑同时采用。
dlmalloc这种内存管理器针对堆内存破坏类型为第二类型，由于内存区间较大，从几十KB至几百兆，因此内存管理逻辑为树管理逻辑和双向链表管理逻辑同时采用。对于不同Size的内存块采用树管理逻辑，对于相同Size的内存块采用双向链表管理逻辑。
例如，对于256字节至512字节的内存块，采用树管理这个内存区间(256字节至512字节)，树的父节点管理512字节，父节点挂两个子节点：左节点A1和右节点B1，左节点A1管理256字节至384字节，右节点B1管理384字节至512字节。
若此时释放了400字节的内存块，这个400字节的内存块就挂在右节点B1的子节点(记为左节点A2)上，左节点A2管理400字节，也即对于不同Size的内存块采用树管理逻辑。
若此时又释放了400字节的内存块，则这个400字节的内存块就和左节点A2管理的400字节的内存块以双向链表的形式进行管理，也即相同Size的内存块采用双向链表管理逻辑。
可见，电子设备基于堆内存破坏类型为第二类型，以树管理逻辑和双向链表管理逻辑排查内存时，首先对树中各节点以树管理逻辑进行排查；其次，在以树管理逻辑进行排查后，对树中以双向链表管理的节点以双向链表管理逻辑进行排查，可确定发生堆内存破坏的第一内存块。
实施例5，在一些实施例中，电子设备确定堆内存破坏类型前，监控第一堆内存破坏接口；在监控到调用第一堆内存破坏接口后，调用第二堆内存破坏接口；在调用第二堆内存破坏接口后，执行确定堆内存破坏类型的步骤。另外，电子设备确定堆内存破坏信息后，返回第一堆内存破坏接口对应的函数，以执行第一堆内存破坏接口对应的函数。
本实施例中，通过监控第一堆内存破坏接口，可以确认是否发生堆内存破坏。当操作系统调用第一堆内存破坏接口，则可确认已发生堆内存破坏。
在一些实施例中，监控第一堆内存破坏接口可以通过对第一堆内存破坏接口设置钩子(hook)函数来实现，hook函数是一种用于改变应用程序编程接口(ApplicationProgramming Interface，API)执行结果的技术，实施例中提及的第一堆内存破坏接口实质上为API接口，hook函数通过修改API接口的入口点，改变API接口的地址指向新的自定义函数。hook函数的实现可以采用开源的hook方案，属于计算机技术领域的成熟技术，不再赘述。
这样，程序在发生堆内存破坏后调用第一堆内存破坏接口时，先调用钩子函数，进而执行自定义的堆内存破坏检测函数，在自定义的堆内存破坏检测函数中实现自定义的堆内存破坏检测步骤，可以获取堆内存破坏相关信息，包括：第一内存块的相关信息和第二内存块的相关信息，便于人工确定发生堆内存破坏的原因和堆内存破坏的位置(内存头部被破坏，还是内存尾部被破坏)等信息，便于动态检测发生破坏的内存块，提高检测效率。
相比第一堆内存破坏接口输出堆内存破坏日志信息，仅知道发生了堆内存破坏，本实施例可获取更多的堆内存破坏相关信息，包括：第一内存块的相关信息和第二内存块的相关信息，便于人工确定发生堆内存破坏的原因和堆内存破坏的位置(内存头部被破坏，还是内存尾部被破坏)等信息。
与操作系统所提供的第一堆内存破坏接口为预设接口不同，本实施例中，第二堆内存破坏接口为自定义接口。第二堆内存破坏接口可以理解为自定义的堆内存破坏检测函数的函数名，其中，自定义的堆内存破坏检测函数中可自定义堆内存破坏检测步骤，进而在调用第二堆内存破坏接口后，可执行自定义堆内存破坏检测步骤，获取堆内存破坏信息，例如发生堆内存破坏的原因和堆内存破坏的位置等。
在一些实施例中，若对第一堆内存破坏接口设置钩子函数来实现第一堆内存破坏接口的监控，那么，操作系统在发生堆内存破坏后调用第一堆内存破坏接口时，先调用钩子函数，进而调用第二堆内存破坏接口，执行在自定义的堆内存破坏检测函数内自定义的堆内存破坏检测步骤。
在一些实施例中，若对第一堆内存破坏接口设置钩子函数来实现第一堆内存破坏接口的监控，那么第二堆内存破坏接口为钩子函数的函数名。这样，操作系统在发生堆内存破坏后调用第一堆内存破坏接口时，先调用钩子函数，进而可执行在钩子函数内自定义的堆内存破坏检测步骤。
本实施例中，由于第一堆内存破坏接口可以理解为堆内存破坏函数的函数名，因此，第一堆内存破坏接口携带的发生堆内存破坏的函数信息可以理解为堆内存破坏函数的参数信息。
例如，Android系统的C标准库中提供的第一堆内存破坏接口为：_bionic_heap_corruption_error，堆内存破坏函数的具体定义如下：
那么，堆内存破坏函数的参数为function，这个function为发生堆内存破坏的函数的函数名，也即function为发生堆内存破坏的函数信息。
在一些实施例中，以dlmalloc这种内存管理器为例，在dlmalloc分配内存的过程中，发生堆内存破坏的函数包括三种：dlmalloc_real，tmalloc_small，tmalloc_large。因此，堆内存破坏函数的参数“function”为dlmalloc_real、tmalloc_small或tmalloc_large。其中，dlmalloc_real用于在小于256字节的空闲内存块中寻找合适的内存块去分配；tmalloc_small和tmalloc_large用于在大于或等于256字节的空闲内存块中寻找合适的内存块去分配。
在一些实施例中，堆内存破坏类型包括第一类型和第二类型，其中，第一类型表示小于256字节的内存块发生破坏，第二类型表示大于或等于256字节的内存块发生破坏。
在一些实施例中，基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息(即function)为dlmalloc_real，则确定堆内存破坏类型为第一类型，也即小于256字节的内存块发生破坏。基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息(即function)为tmalloc_small或tmalloc_large，则确定堆内存破坏类型为第二类型，也即大于或等于256字节的内存块发生破坏。
在一些实施例中，若对第一堆内存破坏接口设置钩子函数来实现第一堆内存破坏接口的监控，那么步骤101可以理解为自定义的堆内存破坏检测函数中自定义的堆内存破坏检测步骤中的一个步骤，也可以理解为在钩子函数内自定义的堆内存破坏检测步骤中的一个步骤。
在一些实施例中，若对第一堆内存破坏接口设置钩子函数来实现第一堆内存破坏接口的监控，那么步骤102可以理解为自定义的堆内存破坏检测函数中自定义的堆内存破坏检测步骤中的一个步骤，也可以理解为在钩子函数内自定义的堆内存破坏检测步骤中的一个步骤。
在一些实施例中，若对第一堆内存破坏接口设置钩子函数来实现第一堆内存破坏接口的监控，那么步骤103可以理解为自定义的堆内存破坏检测函数中自定义的堆内存破坏检测步骤中的一个步骤，也可以理解为在钩子函数内自定义的堆内存破坏检测步骤中的一个步骤。
在一些实施例中，在执行完自定义的堆内存破坏检测函数后，也即执行完步骤101至103后，返回第一堆内存破坏接口对应的函数继续执行，例如，第一堆内存破坏接口为_bionic_heap_corruption_error。在执行完步骤101至103后，返回_bionic_heap_corruption_error继续执行，具体地，输出堆内存破坏日志信息，并退出程序。
可见，本公开的至少一个实施例中，通过监控操作系统提供的第一堆内存破坏接口，在发生堆内存破坏后，先调用自定义的第二堆内存破坏接口，确定堆内存破坏类型，进而可基于不同的堆内存破坏类型采用不同的堆内存破坏检测方式排查内存，确定发生堆内存破坏的第一内存块，从而获取与第一内存块相邻的第二内存块的相关信息，例如第二内存块本身的信息和第二内存块上存储的数据，从而输出第一内存块的相关信息和第二内存块的相关信息，便于确定发生堆内存破坏的原因和堆内存破坏的位置等信息。可见，在每次发生堆内存破坏后，可以输出更多的堆内存破坏相关信息，便于动态检测发生破坏的内存块，提高检测效率。
实施例6，图2是本公开实施例提供的一种应用场景下进行堆内存破坏检测的流程图，本实施例的执行主体为电子设备。
如图2所示，在步骤201中，获取_gm_地址。
本实施例中，dlmalloc这种内存管理器通过全局变量记录堆内存的管理数据，双向链表记录在_gm_变量的smallbins数组中。可通过解析libc库中的全局变量_gm_，获取全局变量_gm_的地址。在一些实施例中，由于libc库加载的较早，因此基于Linux系统ELF(Executable and Linkable Format，可执行与可链接格式)的格式解析libc库，获取_gm_的地址。
在步骤202中，hook堆内存破坏函数。
本实施例中，堆内存破坏函数为操作系统所提供的堆内存破坏接口，记为第一堆内存破坏接口。第一堆内存破坏接口为操作系统在发生堆内存破坏后所调用的接口。第一堆内存破坏接口可以理解为操作系统提供的堆内存破坏函数的函数名，调用第一堆内存破坏接口即为调用堆内存破坏函数。例如，Android系统的C标准库(Libc)中提供的第一堆内存破坏接口为：_bionic_heap_corruption_error。
本实施例中，通过对第一堆内存破坏接口设置钩子(hook)函数来实现监控第一堆内存破坏接口，hook函数是一种用于改变应用程序编程接口(Application ProgrammingInterface，API)执行结果的技术，实施例中提及的第一堆内存破坏接口实质上为API接口，hook函数通过修改API接口的入口点，改变API接口的地址指向新的自定义函数。hook函数的实现可以采用开源的hook方案，属于计算机技术领域的成熟技术，不再赘述。
本实施例中，对第一堆内存破坏接口设置钩子函数后，操作系统在发生堆内存破坏后调用第一堆内存破坏接口时，先调用钩子函数，进而调用第二堆内存破坏接口，执行在自定义的堆内存破坏检测函数内自定义的堆内存破坏检测步骤，可以获取堆内存破坏信息。
与操作系统所提供的第一堆内存破坏接口为预设接口不同，本实施例中，第二堆内存破坏接口为自定义接口。第二堆内存破坏接口可以理解为自定义的堆内存破坏检测函数的函数名，其中，自定义的堆内存破坏检测函数中可自定义堆内存破坏检测步骤，进而在调用第二堆内存破坏接口后，可执行自定义堆内存破坏检测步骤。
在一些实施例中，第二堆内存破坏接口可以为钩子函数的函数名。这样，操作系统在发生堆内存破坏后调用第一堆内存破坏接口时，先调用钩子函数，进而可执行在钩子函数内自定义的堆内存破坏检测步骤。
在步骤203中，确定堆内存破坏类型。本步骤可以理解为自定义的堆内存破坏检测函数中自定义的堆内存破坏检测步骤中的一个步骤，也可以理解为在钩子函数内自定义的堆内存破坏检测步骤中的一个步骤。
本实施例中，在调用第二堆内存破坏接口后，基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息，确定堆内存破坏类型。
本实施例中，由于第一堆内存破坏接口可以理解为堆内存破坏函数的函数名，因此，第一堆内存破坏接口携带的发生堆内存破坏的函数信息可以理解为堆内存破坏函数的参数信息。
例如，Android系统的C标准库中提供的第一堆内存破坏接口为：_bionic_heap_corruption_error，堆内存破坏函数的具体定义如下：
那么，堆内存破坏函数的参数为function，这个function为发生堆内存破坏的函数的函数名，也即function为发生堆内存破坏的函数信息。
在一些实施例中，以dlmalloc这种内存管理器为例，在dlmalloc分配内存的过程中，发生堆内存破坏的函数包括三种：dlmalloc_real，tmalloc_small，tmalloc_large。因此，堆内存破坏函数的参数“function”为dlmalloc_real、tmalloc_small或tmalloc_large。其中，dlmalloc_real用于在小于256字节的空闲内存块中寻找合适的内存块去分配；tmalloc_small和tmalloc_large用于在大于或等于256字节的空闲内存块中寻找合适的内存块去分配。
在一些实施例中，堆内存破坏类型包括第一类型和第二类型，其中，第一类型表示小于256字节的内存块发生破坏，第二类型表示大于或等于256字节的内存块发生破坏。
在一些实施例中，基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息(即function)为dlmalloc_real，则确定堆内存破坏类型为第一类型，也即小于256字节的内存块发生破坏。基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息(即function)为tmalloc_small或tmalloc_large，则确定堆内存破坏类型为第二类型，也即大于或等于256字节的内存块发生破坏。
在步骤204中，确定发生堆内存破坏的内存块。本步骤可以理解为自定义的堆内存破坏检测函数中自定义的堆内存破坏检测步骤中的一个步骤，也可以理解为在钩子函数内自定义的堆内存破坏检测步骤中的一个步骤。
本实施例中，可基于堆内存破坏类型和内存管理器的内存管理逻辑对内存进行排查得到发生堆内存破坏的第一内存块。内存管理器为预先安装在电子设备中的内存管理器，且内存管理逻辑可预先获取到。需要说明的是，不同内存管理器的内存管理逻辑不同，因此，检查第一内存块的方式也不同。另外，同一内存管理器针对不同堆内存破坏类型，也具有不同的内存管理逻辑，因此，检查第一内存块的方式也不同。
在一些实施例中，基于堆内存破坏类型为第一类型，以预设的双向链表管理逻辑排查内存，得到发生堆内存破坏的第一内存块。基于堆内存破坏类型为第二类型，以预设的树管理逻辑和预设的双向链表管理逻辑排查内存，得到发生堆内存破坏的第一内存块。
在获取_gm_的地址后，通过遍历_gm_变量的smallbins数组找到至少一个双向链表的入口，通过遍历这些双向链表的节点，基于内存管理器的双向链表管理逻辑排查内存，确定链表节点是否被破坏。
以dlmalloc这种内存管理器为例，dlmalloc按照内存块的大小，采用了两种内存管理方式，具体地，对于小于256字节的空闲内存块，采用双向链表的管理方式；大于或等于256字节的空闲内存块采用了树加链表的管理方式。
在一些实施例中，基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息(即function)为dlmalloc_real，则确定堆内存破坏类型为第一类型，也即小于256字节的内存块发生破坏。相应地，dlmalloc这种内存管理器针对堆内存破坏类型为第一类型，内存管理逻辑为双向链表管理逻辑：对双向链表中第一内存块的相邻节点进行排查，确定具体包括：节点地址合法性排查和节点链表合法性排查。
节点地址合法性排查：检查节点地址是否大于或等于堆内存的最小地址，若是，则节点地址合法。
节点链表合法性排查：如节点A，节点B相邻，且节点A指向的下一个节点为节点B，则节点B指向的前一个节点必须是节点A，否则节点链表不合法，即节点B不合法，节点B对应的内存块发生了堆内存破坏。
在一些实施例中，dlmalloc这种内存管理器针对堆内存破坏类型为第二类型，由于内存区间较大，从几十KB至几百兆，因此内存管理逻辑为树管理逻辑和双向链表管理逻辑同时采用。对于不同Size的内存块采用树管理逻辑，对于相同Size的内存块采用双向链表管理逻辑。
树管理逻辑包括节点地址合法性排查和节点树合法性排查。
节点地址合法性排查：检查节点地址是否大于或等于堆内存的最小地址，若是，则节点地址合法。
节点树合法性排查：父节点应当指向左节点和右节点，同时左节点和右节点也应当指向父节点，若父节点指向右节点，但右节点不指向父节点，则节点树不合法，即右节点不合法，右节点对应的内存块发生了堆内存破坏。
例如，对于256字节至512字节的内存块，采用树管理这个内存区间(256字节至512字节)，树的父节点管理512字节，父节点挂两个子节点：左节点A1和右节点B1，左节点A1管理256字节至384字节，右节点B1管理384字节至512字节。
若此时释放了400字节的内存块，这个400字节的内存块就挂在右节点B1的子节点(记为左节点A2)上，左节点A2管理400字节，也即对于不同Size的内存块采用树管理逻辑。
若此时又释放了400字节的内存块，则这个400字节的内存块就和左节点A2管理的400字节的内存块以双向链表的形式进行管理，也即相同Size的内存块采用双向链表管理逻辑。
可见，对于堆内存破坏类型为第二类型，以树管理逻辑和双向链表管理逻辑排查内存，得到发生堆内存破坏的第一内存块。
在步骤205中，获取内存块的相关信息并输出。本步骤可以理解为自定义的堆内存破坏检测函数中自定义的堆内存破坏检测步骤中的一个步骤，也可以理解为在钩子函数内自定义的堆内存破坏检测步骤中的一个步骤。
本实施例中，获取与第一内存块相邻的第二内存块的相关信息以及第一内存块的相关信息。
对于双向链表的管理方式，与第一内存块相邻的第二内存块包括两个：第一内存块的前驱节点和第一内存块的后继节点。其中，前驱节点和后继节点均为内存块。
对于树的管理方式，与第一内存块相邻的第二内存块包括两个：第一内存块的父节点和第一内存块的子节点。其中，父节点和子节点实质上均为内存块，一个父节点对应两个子节点，分别称为父节点的左节点和右节点。
第二内存块的相关信息可包括第二内存块本身的信息，例如第二内存块的状态、第二内存块的容量(Size)等。其中，第二内存块的状态为使用中(in used)或空闲(free)。在一些实施例中，第二内存块的相关信息还可包括与第二内存块相邻的内存块本身的信息。在一些实施例中，第二内存块的相关信息还可包括第二内存块上存储的应用数据。
第一内存块的相关信息可包括第一内存块本身的信息，例如第一内存块的状态、第一内存块的容量(Size)等。其中，第一内存块的状态为使用中(in used)或空闲(free)。在一些实施例中，第一内存块的相关信息还可包括第一内存块上存储的应用数据。
在每次发生堆内存破坏后，相比第一堆内存破坏接口输出堆内存破坏日志信息，仅知道发生了堆内存破坏，本实施例可以输出更多的堆内存破坏相关信息，包括：第一内存块的相关信息和第二内存块的相关信息，便于人工确定发生堆内存破坏的原因和堆内存破坏的位置(内存头部被破坏，还是内存尾部被破坏)等信息，便于动态检测发生破坏的内存块，提高检测效率。
在每次发生堆内存破坏后，均可以确定堆内存破坏相关信息，实现动态检测发生破坏的内存块，另外，在退出程序之前可以dump几KB的数据以便于分析和解决堆内存破坏的问题，提升检测效率。其中，dump一般指将数据导出、转存成文件或静态形式。比如可以理解成：把内存某一时刻的内容，dump(转存，导出，保存)成文件。
在一些实施例中，在执行完自定义的堆内存破坏检测函数后，也即执行完步骤203至205后，返回第一堆内存破坏接口对应的函数继续执行，例如，第一堆内存破坏接口为_bionic_heap_corruption_error。在执行完步骤203至205后，返回_bionic_heap_corruption_error继续执行，具体地，输出堆内存破坏日志信息，并退出程序。
可见，本公开的至少一个实施例中，通过监控操作系统提供的第一堆内存破坏接口，在发生堆内存破坏后，先调用自定义的第二堆内存破坏接口，确定堆内存破坏类型，进而可基于不同的堆内存破坏类型采用不同的堆内存破坏检测方式排查内存，确定发生堆内存破坏的第一内存块，从而获取与第一内存块相邻的第二内存块的相关信息，例如第二内存块本身的信息和第二内存块上存储的数据，从而输出第一内存块的相关信息和第二内存块的相关信息，便于确定发生堆内存破坏的原因和堆内存破坏的位置等信息。可见，在每次发生堆内存破坏后，可以输出更多的堆内存破坏相关信息，便于动态检测发生破坏的内存块，提高检测效率。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员能够理解，本公开实施例并不受所描述的动作顺序的限制，因为依据本公开实施例，某些步骤可以采用其他顺序或者同时进行。另外，本领域技术人员能够理解，说明书中所描述的实施例均属于可选实施例。
图3是本公开实施例提供的一种堆内存破坏检测装置的示例性框图，堆内存破坏检测装置可包括确定单元31、获取单元32和输出单元33。
确定单元31，用于基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息，确定堆内存破坏类型。
获取单元32，用于基于堆内存破坏类型，确定发生堆内存破坏的第一内存块，并获取与第一内存块相邻的第二内存块的相关信息以及第一内存块的相关信息；
输出单元33，用于输出第一内存块的相关信息和第二内存块的相关信息。
在一些实施例中，堆内存破坏类型包括第一类型和第二类型；第一类型包括存储容量小于256字节的内存块，第二类型包括存储容量大于或等于256字节的内存块。
在一些实施例中，获取单元32基于堆内存破坏类型，确定发生堆内存破坏的第一内存块包括：
基于堆内存破坏类型为第一类型，以双向链表管理逻辑排查内存，得到发生堆内存破坏的第一内存块；
基于堆内存破坏类型为第二类型，以树管理逻辑和双向链表管理逻辑排查内存，得到发生堆内存破坏的第一内存块。
在一些实施例中，获取单元32可解析预先加载的标准库，获取用于记录堆内存的管理数据的全局变量地址；基于全局变量地址，确定全局变量中用于记录双向链表的数组；遍历数组，确定至少一个双向链表的入口；基于至少一个双向链表的入口，以双向链表管理逻辑排查内存。
在一些实施例中，获取单元32基于堆内存破坏类型为第二类型，以树管理逻辑和双向链表管理逻辑排查内存包括：对树中各节点以树管理逻辑进行排查；在以树管理逻辑进行排查后，对树中以双向链表管理的节点以双向链表管理逻辑进行排查。
在一些实施例中，第二内存块的相关信息包括以下至少一种：第二内存块本身的信息、与第二内存块相邻的内存块本身的信息和第二内存块上存储的应用数据。
在一些实施例中，堆内存破坏检测装置还可包括图3中未示出的监控单元和调用单元。
监控单元，用于监控第一堆内存破坏接口。
调用单元，用于在监控到调用第一堆内存破坏接口后，调用第二堆内存破坏接口。
确定单元31在调用单元调用第二堆内存破坏接口后，基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息，确定堆内存破坏类型。
调用单元在输出单元33输出第一内存块的相关信息和第二内存块的相关信息后，返回第一堆内存破坏接口对应的函数，以执行第一堆内存破坏接口对应的函数。
堆内存破坏检测装置中各单元的具体实施细节可参考堆内存破坏检测方法各步骤的描述，为避免重复，不再赘述。
在一些实施例中，堆内存破坏检测装置中各单元的划分仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如堆内存破坏检测装置中至少两个单元可以实现为一个单元；堆内存破坏检测装置中各单元也可以划分为多个子单元。可以理解的是，各个单元或子单元能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能。
图4是本公开实施例提供的一种电子设备的结构示意图。如图4所示，电子设备包括：至少一个处理器41、至少一个存储器42和至少一个通信接口43。电子设备中的各个组件通过总线系统44耦合在一起。通信接口43，用于与外部设备之间的信息传输。可理解地，总线系统44用于实现这些组件之间的连接通信。总线系统44除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但为了清楚说明起见，在图4中将各种总线都标为总线系统44。
可以理解，本实施例中的存储器42可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。
在一些实施方式中，存储器42存储了如下的元素，可执行单元或者数据结构，或者他们的子集，或者他们的扩展集：操作系统和应用程序。
其中，操作系统，包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础任务以及处理基于硬件的任务。应用程序，包含各种应用程序，例如媒体播放器(Media Player)、浏览器(Browser)等，用于实现各种应用任务。实现本公开实施例提供的堆内存破坏检测方法的程序可以包含在应用程序中。
在本公开实施例中，处理器41通过调用存储器42存储的程序或指令，具体的，可以是应用程序中存储的程序或指令，处理器41用于执行本公开实施例提供的堆内存破坏检测方法各实施例的步骤。
本公开实施例提供的堆内存破坏检测方法可以应用于处理器41中，或者由处理器41实现。处理器41可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器41中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器41可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(FieldProgrammable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
本公开实施例提供的堆内存破坏检测方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件单元组合执行完成。软件单元可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器42，处理器41读取存储器42中的信息，结合其硬件完成方法的步骤。
本公开实施例还提出一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如堆内存破坏检测方法各实施例的步骤，为避免重复描述，在此不再赘述。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本公开的范围之内并且形成不同的实施例。
本领域的技术人员能够理解，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
虽然结合附图描述了本公开的实施方式，但是本领域技术人员可以在不脱离本公开的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。
Claims (10)
1.一种堆内存破坏检测方法，其特征在于，所述方法包括：
基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息，确定堆内存破坏类型；
基于所述堆内存破坏类型，确定发生堆内存破坏的第一内存块，并获取所述第一内存块的相关信息、以及与所述第一内存块相邻的第二内存块的相关信息；
输出所述第一内存块的相关信息和所述第二内存块的相关信息。
2.根据权利要求1所述的方法，其特征在于，所述堆内存破坏类型包括第一类型和第二类型；
所述第一类型包括存储容量小于256字节的内存块，所述第二类型包括存储容量大于或等于256字节的内存块。
3.根据权利要求2所述的方法，其特征在于，所述基于堆内存破坏类型，确定发生堆内存破坏的第一内存块包括：
基于所述堆内存破坏类型为第一类型，以双向链表管理逻辑排查内存，得到发生堆内存破坏的第一内存块；
基于所述堆内存破坏类型为第二类型，以树管理逻辑和双向链表管理逻辑排查内存，得到发生堆内存破坏的第一内存块。
4.根据权利要求3所述的方法，其特征在于，所述以双向链表管理逻辑排查内存之前，所述方法还包括：
解析预先加载的标准库，获取用于记录堆内存的管理数据的全局变量地址；
基于所述全局变量地址，确定全局变量中用于记录双向链表的数组；
遍历所述数组，确定至少一个双向链表的入口；
相应地，所述以双向链表管理逻辑排查内存包括：
基于所述至少一个双向链表的入口，以所述双向链表管理逻辑排查内存。
5.根据权利要求3所述的方法，其特征在于，所述以树管理逻辑和双向链表管理逻辑排查内存包括：
对树中各节点以树管理逻辑进行排查；
在以树管理逻辑进行排查后，对所述树中以双向链表管理的节点以双向链表管理逻辑进行排查。
6.根据权利要求1所述的方法，其特征在于，所述第二内存块的相关信息包括以下至少一种：所述第二内存块本身的信息、与所述第二内存块相邻的内存块本身的信息和所述第二内存块上存储的应用数据。
7.根据权利要求1所述的方法，其特征在于，所述确定堆内存破坏类型前，所述方法还包括：
监控第一堆内存破坏接口；
在监控到调用所述第一堆内存破坏接口后，调用第二堆内存破坏接口；
在调用所述第二堆内存破坏接口后，执行所述确定堆内存破坏类型；
所述确定堆内存破坏信息后，所述方法还包括：
返回所述第一堆内存破坏接口对应的函数，以执行所述第一堆内存破坏接口对应的函数。
8.一种堆内存破坏检测装置，其特征在于，所述装置包括：
确定单元，用于基于第一堆内存破坏接口携带的发生堆内存破坏的函数信息，确定堆内存破坏类型；
获取单元，用于基于堆内存破坏类型，确定发生堆内存破坏的第一内存块，并获取与所述第一内存块相邻的第二内存块的相关信息以及所述第一内存块的相关信息；
输出单元，用于输出所述第一内存块的相关信息和所述第二内存块的相关信息。
9.一种电子设备，其特征在于，包括：处理器和存储器；
所述处理器通过调用所述存储器存储的程序或指令，用于执行如权利要求1至7任一项所述方法的步骤。
10.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如权利要求1至7任一项所述方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110504336.1A CN113157513A (zh) | 2021-05-10 | 2021-05-10 | 一种堆内存破坏检测方法、装置、电子设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110504336.1A CN113157513A (zh) | 2021-05-10 | 2021-05-10 | 一种堆内存破坏检测方法、装置、电子设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113157513A true CN113157513A (zh) | 2021-07-23 |
Family
ID=76874064
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110504336.1A Pending CN113157513A (zh) | 2021-05-10 | 2021-05-10 | 一种堆内存破坏检测方法、装置、电子设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113157513A (zh) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101110044A (zh) * | 2007-08-28 | 2008-01-23 | 中兴通讯股份有限公司 | 一种内存监控管理的方法及系统 |
| CN109558297A (zh) * | 2018-11-27 | 2019-04-02 | 苏州思必驰信息科技有限公司 | 内存管理方法及装置 |
| CN109656779A (zh) * | 2018-12-07 | 2019-04-19 | 广州市百果园信息技术有限公司 | 内存监控方法、装置、终端和存储介质 |
| US20190318126A1 (en) * | 2018-04-16 | 2019-10-17 | First Data Corporation | System and method for storing data used by breach detection systems |
| CN110413521A (zh) * | 2019-07-24 | 2019-11-05 | 杭州迪普信息技术有限公司 | 一种堆内存的写越界检测方法和装置 |
| CN111078540A (zh) * | 2019-11-29 | 2020-04-28 | 四川九洲空管科技有限责任公司 | 基于qt开发通用航空飞行服务软件内存异常检测定位方法 |
| CN111813666A (zh) * | 2020-06-30 | 2020-10-23 | 北京字节跳动网络技术有限公司 | 一种内存泄露定位的方法、装置、介质和电子设备 |
| CN112631821A (zh) * | 2021-01-28 | 2021-04-09 | 长沙景嘉微电子股份有限公司 | 内存故障检测定位方法、装置、计算机设备及存储介质 |
-
2021
- 2021-05-10 CN CN202110504336.1A patent/CN113157513A/zh active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101110044A (zh) * | 2007-08-28 | 2008-01-23 | 中兴通讯股份有限公司 | 一种内存监控管理的方法及系统 |
| US20190318126A1 (en) * | 2018-04-16 | 2019-10-17 | First Data Corporation | System and method for storing data used by breach detection systems |
| CN109558297A (zh) * | 2018-11-27 | 2019-04-02 | 苏州思必驰信息科技有限公司 | 内存管理方法及装置 |
| CN109656779A (zh) * | 2018-12-07 | 2019-04-19 | 广州市百果园信息技术有限公司 | 内存监控方法、装置、终端和存储介质 |
| CN110413521A (zh) * | 2019-07-24 | 2019-11-05 | 杭州迪普信息技术有限公司 | 一种堆内存的写越界检测方法和装置 |
| CN111078540A (zh) * | 2019-11-29 | 2020-04-28 | 四川九洲空管科技有限责任公司 | 基于qt开发通用航空飞行服务软件内存异常检测定位方法 |
| CN111813666A (zh) * | 2020-06-30 | 2020-10-23 | 北京字节跳动网络技术有限公司 | 一种内存泄露定位的方法、装置、介质和电子设备 |
| CN112631821A (zh) * | 2021-01-28 | 2021-04-09 | 长沙景嘉微电子股份有限公司 | 内存故障检测定位方法、装置、计算机设备及存储介质 |
Non-Patent Citations (3)
| Title |
|---|
| 李仁见;刘万伟;王昭飞;吴学光;: "精确的堆内存使用量上界分析", 武汉大学学报(理学版), no. 06 * |
| 裴中煜;张超;段海新;: "Glibc堆利用的若干方法", 信息安全学报, no. 01 * |
| 陈俞飞;陈榕;: "Elastos内存管理对软件调试的支持", 计算机技术与发展, no. 04 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7774741B2 (en) | Automatically resource leak diagnosis and detecting process within the operating system | |
| US8250543B2 (en) | Software tracing | |
| CN109656779A (zh) | 内存监控方法、装置、终端和存储介质 | |
| CN110992992A (zh) | 一种硬盘测试方法、设备以及存储介质 | |
| CN109086183B (zh) | 一种应用程序的监控方法、装置、电子设备及存储介质 | |
| CN110737892B (zh) | 一种针对apc注入的检测方法和相关装置 | |
| KR102545765B1 (ko) | 메모리 오류를 검출하는 방법 및 시스템 | |
| CN110879781A (zh) | 程序调试方法、装置、电子设备及计算机可读存储介质 | |
| US9575827B2 (en) | Memory management program, memory management method, and memory management device | |
| CN111353143A (zh) | 敏感权限检测方法、装置及存储介质 | |
| CN112214388A (zh) | 内存监控方法、装置、设备及计算机可读存储介质 | |
| CN115407943A (zh) | 一种内存转储文件生成方法、装置、设备及可读存储介质 | |
| KR102254159B1 (ko) | 운영체제 커널 메모리의 실시간 오류 검출 방법 | |
| CN113987507A (zh) | 堆内存漏洞检测方法、装置、存储介质及电子设备 | |
| CN111274130A (zh) | 一种自动化测试方法、装置、设备及存储介质 | |
| CN113468009A (zh) | 一种压力测试方法、装置、电子设备及存储介质 | |
| US20110202903A1 (en) | Apparatus and method for debugging a shared library | |
| CN111435327B (zh) | 一种日志记录的处理方法、装置及系统 | |
| US10417121B1 (en) | Monitoring memory usage in computing devices | |
| CN108197041B (zh) | 一种确定子进程的父进程的方法、设备及其存储介质 | |
| US20120144136A1 (en) | Restoration of data from a backup storage volume | |
| CN111522598A (zh) | 嵌入式设备的重启信息记录方法及装置 | |
| US9436575B2 (en) | Selective profiling of applications | |
| CN113157513A (zh) | 一种堆内存破坏检测方法、装置、电子设备及存储介质 | |
| US8280927B2 (en) | Electronic equipment and memory managing program |
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 |