Linux内核的内存泄漏检测方法和装置、介质、设备

摘要

本公开涉及一种Linux内核的内存泄漏检测方法和装置、介质、设备。所述方法包括：利用内核插桩技术，对内存分配函数插桩，随机捕获一个内核内存分配动作，记录内存分配返回的内存地址并设置监控标志；监测当前记录的内存地址在预定的时长内是否释放；若当前记录的内存地址在所述预定的时长内未释放，则判定当前记录的内存地址泄漏；利用内核插桩技术，捕获内核内存的释放动作，利用内存释放的插桩函数判断该释放的内存地址是否为当前记录的内存地址；若判定该释放的内存地址为当前记录的内存地址，则将当前记录的内存地址和所述监控标志删除，并随机捕获下一个内核内存分配动作。本方案能够在正式上线产品中动态追踪Linux内核内存泄漏。

说明书

技术领域

本公开涉及终端设备的监测技术领域，具体地，涉及一种Linux内核的内存泄漏检测方法和装置、介质、设备。

背景技术

内存泄漏(Memory Leak)是指程序中已动态分配的堆内存，由于某种原因，程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢，甚至系统崩溃等严重后果。

内存泄漏缺陷具有隐蔽性、积累性的特征，比其他内存非法访问错误更难检测。因为内存泄漏产生的原因是内存块未被释放，属于遗漏型缺陷而不是过错型缺陷。此外，内存泄漏通常不会直接产生可观察的错误症状，而是逐渐积累，降低系统整体性能，极端的情况下才可能使系统崩溃。

在相关技术中，在Linux系统中对于内存泄漏的检测方法有两种。第一，通过Linux内核自带的kmemleak方案记录所有调用分配内存函数(如：kmalloc)的过程。该方案中，会创建许多额外的数据，增加系统的额外负载，输出信息多，不适合线上的环境。第二，可以基于ebpf的用户态bcc工具集(python脚本)来检测，该方案会采集所有的分配内存过程，输出的干扰信息较多，不利于排查问题。

发明内容

本公开的目的是提供一种能够在正式上线产品中动态检测Linux内核内存泄漏的方法和装置、介质、设备。

为了实现上述目的，本公开提供一种Linux内核的内存泄漏检测方法，所述方法包括：

利用内核插桩技术，对内存分配函数插桩，随机捕获一个内核内存分配动作，记录内存分配返回的内存地址并设置监控标志；

监测当前记录的内存地址在预定的时长内是否释放；

若当前记录的内存地址在所述预定的时长内未释放，则判定当前记录的内存地址泄漏；

利用内核插桩技术，捕获内核内存的释放动作，利用内存释放的插桩函数判断该释放的内存地址是否为当前记录的内存地址；

若判定该释放的内存地址为当前记录的内存地址，则将当前记录的内存地址和所述监控标志删除，并随机捕获下一个内核内存分配动作。

可选地，所述方法还包括：

若判定当前记录的内存地址泄漏，则将当前记录的内存地址和所述监控标志删除，并随机捕获下一个内核内存分配动作。

可选地，在利用内核插桩技术，对内存分配函数插桩，随机捕获一个内核内存分配动作，记录内存分配返回的内存地址并设置监控标志之前，所述方法还包括：

监测各个内存块是否有内存泄漏的可能性；

若一内存块有内存泄漏的可能性，则载入内核模块，以由所述内核模块利用内核插桩技术，对内存分配函数插桩，随机捕获一个内核内存分配动作；

其中，随机捕获一个内核内存分配动作，包括：在有内存泄漏可能性的内存块中随机捕获一个内核内存分配动作；

随机捕获下一个内核内存分配动作，包括：在有内存泄漏可能性的内存块中随机捕获下一个内核内存分配动作。

可选地，监测各个内存块是否有内存泄漏的可能性，包括：

监测各个内存块中已使用内存的大小；

若一内存块中已使用的内存大于该内存块对应的阈值，则判定该内存块有内存泄漏的可能性。

可选地，在载入所述内核模块之后，所述方法还包括：

若没有新的内存块被判定为具有内存泄漏的可能性，则卸载所述内核模块。

可选地，所述方法还包括：

记录内存分配返回的内存地址对应的调用栈；

若判定当前记录的内存地址泄漏，则将当前记录的内存地址对应的调用栈打印到缓存中。

可选地，所述方法还包括：

将已释放的内存地址对应的调用栈删除；和/或，将已打印的调用栈删除。

可选地，所述缓存为环形缓存。

可选地，所述方法还包括：

定期扫描所述环形缓存；

若根据所述环形缓存中的数据判定存在内存泄漏，则向服务器发送提示消息。

本公开还提供一种Linux内核内存泄漏检测装置，所述装置包括：

捕获模块，用于利用内核插桩技术，对内存分配函数插桩，随机捕获一个内核内存分配动作，记录内存分配返回的内存地址并设置监控标志；

第一监测模块，用于监测当前记录的内存地址在预定的时长内是否释放；

第一判断模块，用于若当前记录的内存地址在所述预定的时长内未释放，则判定当前记录的内存地址泄漏；

第二判断模块，用于利用内核插桩技术，捕获内核内存的释放动作，利用内存释放的插桩函数判断该释放的内存地址是否为当前记录的内存地址；

第一返回模块，用于若判定该释放的内存地址为当前记录的内存地址，则将当前记录的内存地址和所述监控标志删除，并随机捕获下一个内核内存分配动作。

可选地，所述装置还包括：

第二返回模块，用于若判定当前记录的内存地址泄漏，则将当前记录的内存地址和所述监控标志删除，并随机捕获下一个内核内存分配动作。

可选地，所述装置还包括：

第二监测模块，用于监测各个内存块是否有内存泄漏的可能性；

载入模块，用于若一内存块有内存泄漏的可能性，则载入内核模块，以由所述内核模块利用内核插桩技术，对内存分配函数插桩，随机捕获一个内核内存分配动作；

其中，所述捕获模块用于在有内存泄漏可能性的内存块中随机捕获一个内核内存分配动作；

所述第一返回模块用于在有内存泄漏可能性的内存块中随机捕获下一个内核内存分配动作。

可选地，所述第二监测模块包括：

检测子模块，用于监测各个内存块中已使用内存的大小；

判断子模块，用于若一内存块中已使用的内存大于该内存块对应的阈值，则判定该内存块有内存泄漏的可能性。

本公开还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本公开提供的上述方法的步骤。

本公开还提供一种电子设备，包括：

存储器，其上存储有计算机程序；

处理器，用于执行所述存储器中的所述计算机程序，以实现本公开提供的上述方法的步骤。

通过上述技术方案，基于Linux内核提供的静态插桩技术(tracepoint)，对内核内存分配函数和内存释放函数成对监控，能够在正式上线产品中动态追踪Linux内核内存泄漏，并且一次只监控一个内存地址，极大地降低了系统的额外负载(overhead)，每次监控的内存地址是随机的一个地址，因此对系统副作用极低。

本公开的其他特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

附图是用来提供对本公开的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开，但并不构成对本公开的限制。在附图中：

图1是一示例性实施例提供的内存泄漏检测方法的流程图；

图2是另一示例性实施例提供的内存泄漏检测方法的流程图；

图3是又一示例性实施例提供的内存泄漏检测方法的流程图；

图4是又一示例性实施例提供的内存泄漏检测方法的流程图；

图5是又一示例性实施例提供的内存泄漏检测方法的流程图；

图6是一示例性实施例提供的内存泄漏检测装置的框图；

图7是一示例性实施例示出的一种电子设备的框图。

具体实施方式

以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本公开，并不用于限制本公开。

如上所述，在相关技术中，可以通过Linux内核自带的kmemleak方案会记录所有调用分配内存函数的过程，其具体步骤如下。

1、kmemleak需要重新编译内核，对于车机还需要新刷机，不适合正在运行的设备。

2、默认kmemleak会创建一个内核线程，例如每隔10分钟扫描一次，也可以从用户态手动触发。

3、扫描过程会跟踪kmalloc、vmalloc、kmem_cache_alloc等内存分配(不包括alloc_pages)返回的的指针，由于它记录了所有分配过程调用栈，所以会造成大量的额外负载，当10分钟内对应的指针没有释放，则认为是内存泄漏。

该方案的缺点是即使系统没有内存泄漏，也会一直扫描，消耗系统资源，并且会创建许多额外的数据，增加系统的额外负载，输出信息多，不适合线上环境。

另外，可以基于ebpf的用户态bcc工具集来采集所有的分配内存过程，其具体步骤如下。

1、ebpf通过实际验证在Android系统上需要安装debian环境，还需要内核较高版本(例如，5.4以上版本)支持才能正确地检测到内核内存泄漏。所以首先是编译Android的debian环境，这会占据系统较多的存储资源。

2、ebpf的bcc工具集提供了memleak的python工具，直接运行来检测内存泄漏，同kmemleak一样，也是所有的内存分配调用过程全部监控。

该方案中，ebpf(bcc)的memleak会产生大量的输出，输出的干扰信息很多,不利于排查问题。

本公开提供一种能够在正式上线产品中动态检测Linux系统中内核内存泄漏的方法和装置、介质、设备，能够极大地降低系统的额外负载。

图1是一示例性实施例提供的内存泄漏检测方法的流程图。如图1所示，该方法可以包括以下步骤。

步骤S11，利用内核插桩技术，对内存分配函数插桩，随机捕获一个内核内存分配动作，记录内存分配返回的内存地址并设置监控标志。

步骤S12，监测当前记录的内存地址在预定的时长内是否释放。

步骤S13，若当前记录的内存地址在预定的时长内未释放，则判定当前记录的内存地址泄漏。

步骤S14，利用内核插桩技术，捕获内核内存的释放动作，利用内存释放的插桩函数判断该释放的内存地址是否为当前记录的内存地址。

步骤S15，若判定该释放的内存地址为当前记录的内存地址，则将当前记录的内存地址和监控标志删除，并随机捕获下一个内核内存分配动作。

本方案针对Linux系统。本方案的实现可以以kernel module的形式存在，需要insmod xxx.ko或者编译进vmlinux。基于Linux内核提供的tracepoint静态插桩技术，对常用的内核内存分配函数和释放函数成对监控。其中，分配函数为xxx_alloc，释放函数为xxx_free。

动态insmod的内核模块可以通过tracepoint给xxx_alloc函数插桩，插桩函数可以内部判断是否记录有监控标志，没有的话，在步骤S11中，将随机捕获的一段内存对应的地址进行记录，例如可以记录在监控列表中，并设置监控标志。具体地，使能内核内存分配函数插桩功能，钩子函数会捕获所有被打桩的内存分配和释放动作，随机捕获其中一个内存分配动作。

若当前设置有监控标志，则不捕获下一个内存地址，若当前未设置有监控标志，则可以捕获下一个内存地址。因此，监控标志表示插桩函数同时只会监控一个内存地址。

接着，在步骤S12中，可以启动一个高精度定时器，定时去判断监控列表里的地址是否释放并进行计时。例如，认为正常的内存使用在10min内会释放掉，在步骤S13中，监测一记录的内存地址在10min内是否释放，若未释放，则判定该内存地址泄漏。

在步骤S14中，可以在xxx_free函数中插桩，插桩函数判断释放的内存地址是否为当前记录的内存地址，即判断准备释放的内存地址是否在监控列表里。也就是，若内存释放的插桩函数捕获到内存释放动作，对比释放的内存地址是否为之前记录并监控的内存地址。

在步骤S15中，若该释放的内存地址为当前记录的内存地址，则可以将当前记录的内存地址删除，即将当前监控的地址从监控列表清除，并且清除监控标志，代表xxx_alloc的插桩函数又可以监控下一个内存地址了。然后再随机捕获下一个内存地址。这样能够在同一时刻只监控一个内存地址。

通过上述技术方案，基于Linux内核提供的静态插桩技术，对内核内存分配函数和内存释放函数成对监控，能够在正式上线产品中动态追踪Linux内核内存泄漏，并且一次只监控一个内存地址，极大地降低了系统的额外负载，每次监控的内存地址是随机的一个地址，因此对系统副作用极低。

图2是另一示例性实施例提供的内存泄漏检测方法的流程图。如图2所示，在图1的基础上，该方法还可以包括步骤S16。

步骤S16，若判定当前记录的内存地址泄漏，则将当前记录的内存地址和监控标志删除，并随机捕获下一个内核内存分配动作。

其中，若当前记录的内存地址泄漏，即该内存地址在预定的时长内未释放，则主动将记录的该内存地址删除，即从监测列表中删除，这样，捕获了下一个内核内存分配动作后，就可以将释放的内存地址记录在监测列表中，保证监测列表中同时只有一个内存地址，同时只监测一个内存地址。可以设置仅在未设置有监控标志的情况下才能够捕获并记录下一个内核内存分配动作，这样，删除监控标志的目的是为了保证捕获下一个内核内存分配动作能够正常执行，同样保证了同时只监测一个内存地址。

该实施例中，能够保证在监测到有内存地址泄漏的情况下，能够继续对其他内存地址进行监测。

Linux操作系统使用面向对象的设计思想，内核中用到的数据结构(如：进程、文件节点等)使用的内存都是通过内存分配对象池中分配内存，每一种类型的内核对象都对应一个内存块(slab)内存缓存池，并且给用户态提供接口，在用户态使用slabtop工具，可以监控所有不同类型内核对象的slab内存缓存池内内存的使用率。这里的slab是Linux内核将内存物理内存页(通常为4096字节)以更小的单元提供内核为对象提供的内存分配器。

图3是又一示例性实施例提供的内存泄漏检测方法的流程图。如图3所示，在图1的基础上，在利用内存分配函数，随机捕获一个内存地址，记录该内存地址并设置监控标志(步骤S11)之前，该方法还可以包括步骤S101和步骤S102。

步骤S101，监测各个内存块(slab)是否有内存泄漏的可能性。

步骤S102，若一slab有内存泄漏的可能性，则载入内核模块，以由内核模块利用内核插桩技术，对内存分配函数插桩，随机捕获一个内核内存分配动作。

该实施例中，步骤S11中的随机捕获一个内核内存分配动作可以包括：在有内存泄漏可能性的slab中随机捕获一个内核内存分配动作。即步骤S11可以包括步骤S111：利用内核插桩技术，对内存分配函数插桩，在有内存泄漏可能性的slab中随机捕获一个内核内存分配动作，记录内存分配返回的内存地址并设置监控标志。

并且，步骤S15中的随机捕获下一个内核内存分配动作可以包括：在有内存泄漏可能性的slab中随机捕获下一个内核内存分配动作。即步骤S15可以包括步骤S151：若判定该释放的内存地址为当前记录的内存地址，则将当前记录的内存地址和监控标志删除，并在有内存泄漏可能性的slab中随机捕获下一个内核内存分配动作。

在图3的实施例中，预先监测各个slab是否有内存泄漏的可能性，仅在判定一slab有可能内存泄漏的情况下，再载入内核模块，否则并不载入内核模块。

具体地，可以在用户态使用slabtop或者其他工具定时监控各个slab内存的使用情况，来初步判定各个slab是否有内存泄漏的可能性。若有，则用户态可以将文件系统中的内核模块通过insmod命令安装到系统(例如，车机系统)中。

在监控过程中，步骤S111中，可以仅在判定为具有内存泄漏的可能性的slab中捕获内存地址，例如，判定kmalloc-1024的slab有内存泄漏的可能性，则仅捕获分配函数的大小是1024的内存地址，即该slab中的内存地址进行监控，对其他slab中的内存地址不进行监控。

这样，仅在一slab有内存泄漏的可能性的情况下，再载入内核模块，即以module的方式动态安装到内核，以由内核模块利用静态插桩技术对内存分配函数和内存释放函数进行插桩，即灵活地添加内存分配函数。若判定各个slab均没有内存泄漏的可能性，则不载入内核模块进行监测，以避免内核模块长期占用内存空间。并且，动态设置为只监测特定内存大小的内存地址(具有内存泄漏的可能性的slab中的内存地址)，减小系统的额外负载。

其中，监测各个slab是否有内存泄漏的可能性可以包括：监测各个slab中已使用内存的大小；若一slab中已使用的内存大于该slab对应的阈值，则判定该slab有内存泄漏的可能性。

也就是，一slab是否有内存泄漏的可能性，可以由该slab中已使用的内存的大小来判断。预先为每个slab设置对应的阈值，一slab中已使用的内存大于该slab对应的阈值，则判定该slab有内存泄漏的可能性，反之，则判定该slab没有内存泄漏的可能性。该对应的阈值可以是一slab内存缓存池在不泄露的情况下的已使用的内存的最大值。

该实施例中，判断slab内存泄漏的方法简单，易操作，数据处理速度快。

图4是又一示例性实施例提供的内存泄漏检测方法的流程图。如图4所示，在图3的基础上，在载入所述内核模块之后，该方法还包括步骤S17。

步骤S17，若没有新的内存块被判定为具有内存泄漏的可能性，则卸载内核模块。

也就是，在判定没有新的内核泄漏的内存块情况下卸载内核模块，以避免内核模块长期占用内存空间，不给系统造成额外负担。

在又一实施例中，在图1的基础上，该方法还可以包括：记录所捕获内存地址对应的调用栈；若判定当前记录的内存地址泄漏，则将当前记录的内存地址对应的调用栈打印到缓存中。

也就是，若断定了记录的内存地址确实属于内存泄漏，可以将上一步的函数调用栈导出到用户空间，用户空间程序可以进一步将该函数调用栈通过网络上报给服务器，以便通知到对应的开发人员及时处理。

该实施例中，在出现内存泄漏时，将当时分配内存的调用栈打印到缓存中，这样，技术人员能够根据打印到缓存中的调用栈进行分析处理，以增强系统的可靠性。

在又一实施例中，该方法还可以包括：将已释放的内存地址对应的调用栈删除。即对于已释放的内存地址来说，认为其没有内存泄漏，其调用栈可以不作保留，删除其调用栈能够腾出内存空间，不给系统造成额外负担。

在又一实施例中，该方法还可以包括：将已打印的调用栈删除。即对于未在预定时长内释放的内存地址来说，认为其存在内存泄漏，将其调用栈打印在缓存中后就可以不作保留，仅保留缓存中的调用栈，删除已打印的调用栈也能够腾出内存空间，不给系统造成额外负担。

上述的缓存可以为环形缓存，实现先进先出的缓存。在又一实施例中，该方法还可以包括：定期扫描环形缓存；若根据环形缓存中的数据判定存在内存泄漏，则向服务器发送提示消息。

用户态可以定期去扫描环形缓存是否有内存泄漏关键字，若有则上报服务器。服务器可以输出提示消息，以通知相关人员进行分析处理。其中，定期的时长可以根据经验预先确定。这样，可以通过定时去环形缓存查找的方式，确定是否存在有内存泄漏，适合对内存泄漏这种遗漏型缺陷的处理。

图5是又一示例性实施例提供的内存泄漏检测方法的流程图。图5的实施例中，结合了前述多个实施例的技术特征，具体如下。

1、监测各个slab已使用内存的大小；

2、判断是否有slab的已使用内存超过预定范围，若否，则继续监测各个slab已使用内存的大小；

3、若是，则载入内核模块；

4、在该slab中随机捕获一内核内存分配动作，记录内存分配返回的内存地址、设置监控标志；

5、判断是否当前记录的内存地址在预定时长内释放；

6、若否，则判定当前记录的内存地址泄漏，删除当前记录的内存地址和监控标志；

7、若是，则在释放的内存地址为当前记录的内存地址的情况下，删除当前记录的内存地址和监控标志；

8、在没有新的内存块被判定为具有内存泄漏的可能性的情况下结束监测，否则，继续在该slab中随机捕获一内存地址。

图6是一示例性实施例提供的内存泄漏检测装置的框图。如图6所示，内存泄漏检测装置600可以包括捕获模块601、第一监测模块602、第一判断模块603、第二判断模块604和第一返回模块605。

捕获模块601用于利用内核插桩技术，对内存分配函数插桩，随机捕获一个内核内存分配动作，记录内存分配返回的内存地址并设置监控标志。

第一监测模块602用于监测当前记录的内存地址在预定的时长内是否释放。

第一判断模块603用于若当前记录的内存地址在预定的时长内未释放，则判定当前记录的内存地址泄漏。

第二判断模块604用于利用内核插桩技术，捕获内核内存的释放动作，利用内存释放的插桩函数判断该释放的内存地址是否为当前记录的内存地址。

第一返回模块605用于若判定该释放的内存地址为当前记录的内存地址，则将当前记录的内存地址和监控标志删除，并随机捕获下一个内核内存分配动作。

可选地，内存泄漏检测装置600还可以包括第二返回模块。

第二返回模块用于若判定当前记录的内存地址泄漏，则将当前记录的内存地址和监控标志删除，并随机捕获下一个内核内存分配动作。

可选地，内存泄漏检测装置600还可以包括第二监测模块和载入模块。

第二监测模块用于监测各个slab是否有内存泄漏的可能性。

载入模块用于若一slab有内存泄漏的可能性，则载入内核模块，以由内核模块利用内核插桩技术，对内存分配函数插桩，随机捕获一个内核内存分配动作。

其中，捕获模块用于在有内存泄漏可能性的slab中随机捕获一个内核内存分配动作。

第一返回模块用于在有内存泄漏可能性的slab中随机捕获下一个内核内存分配动作。

可选地，第二监测模块可以包括检测子模块和判断子模块。

检测子模块用于监测各个slab中已使用内存的大小。

判断子模块用于若一slab中已使用的内存大于该slab对应的阈值，则判定该slab有内存泄漏的可能性。

可选地，内存泄漏检测装置600还可以包括卸载模块。

卸载模块用于若没有新的内存块被判定为具有内存泄漏的可能性，则卸载内核模块。

可选地，内存泄漏检测装置600还可以包括记录模块和打印模块。

记录模块用于记录内存分配返回的内存地址对应的调用栈。

打印模块用于若判定当前记录的内存地址泄漏，则将当前记录的内存地址对应的调用栈打印到缓存中。

可选地，内存泄漏检测装置600还可以包括第一删除模块。

第一删除模块用于将已释放的内存地址对应的调用栈删除。

可选地，内存泄漏检测装置600还可以包括第二删除模块。

第二删除模块用于将已打印的调用栈删除。

可选地，所述缓存为环形缓存。

可选地，内存泄漏检测装置600还可以包括扫描模块和发送模块。

扫描模块用于定期扫描环形缓存。

发送模块用于若根据环形缓存中的数据判定存在内存泄漏，则向服务器发送提示消息。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

通过上述技术方案，基于Linux内核提供的静态插桩技术，对内核内存分配函数和内存释放函数成对监控，能够在正式上线产品中动态追踪Linux内核内存泄漏，并且一次只监控一个内存地址，极大地降低了系统的额外负载，每次监控的内存地址是随机的一个地址，因此对系统副作用极低。

图7是一示例性实施例示出的一种电子设备700的框图。如图7所示，该电子设备700可以包括：处理器701，存储器702。该电子设备700还可以包括多媒体组件703，输入/输出(I/O)接口704，以及通信组件705中的一者或多者。

其中，处理器701用于控制该电子设备700的整体操作，以完成上述的内存泄漏检测方法中的全部或部分步骤。存储器702用于存储各种类型的数据以支持在该电子设备700的操作，这些数据例如可以包括用于在该电子设备700上操作的任何应用程序或方法的指令，以及应用程序相关的数据，例如联系人数据、收发的消息、图片、音频、视频等等。该存储器702可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，例如静态随机存取存储器(Static Random Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，只读存储器(Read-Only Memory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。多媒体组件703可以包括屏幕和音频组件。其中屏幕例如可以是触摸屏，音频组件用于输出和/或输入音频信号。例如，音频组件可以包括一个麦克风，麦克风用于接收外部音频信号。所接收的音频信号可以被进一步存储在存储器702或通过通信组件705发送。音频组件还包括至少一个扬声器，用于输出音频信号。I/O接口704为处理器701和其他接口模块之间提供接口，上述其他接口模块可以是键盘，鼠标，按钮等。这些按钮可以是虚拟按钮或者实体按钮。通信组件705用于该电子设备700与其他设备之间进行有线或无线通信。无线通信，例如Wi-Fi，蓝牙，近场通信(Near FieldCommunication，简称NFC)，2G、3G、4G、NB-IOT、eMTC、或其他5G等等，或它们中的一种或几种的组合，在此不做限定。因此相应的该通信组件705可以包括：Wi-Fi模块，蓝牙模块，NFC模块等等。

在一示例性实施例中，电子设备700可以被一个或多个应用专用集成电路(Application Specific Integrated Circuit，简称ASIC)、数字信号处理器(DigitalSignal Processor，简称DSP)、数字信号处理设备(Digital Signal Processing Device，简称DSPD)、可编程逻辑器件(Programmable Logic Device，简称PLD)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述的内存泄漏检测方法。

在另一示例性实施例中，还提供了一种包括程序指令的计算机可读存储介质，该程序指令被处理器执行时实现上述的内存泄漏检测方法的步骤。例如，该计算机可读存储介质可以为上述包括程序指令的存储器702，上述程序指令可由电子设备700的处理器701执行以完成上述的内存泄漏检测方法。

以上结合附图详细描述了本公开的优选实施方式，但是，本公开并不限于上述实施方式中的具体细节，在本公开的技术构思范围内，可以对本公开的技术方案进行多种简单变型，这些简单变型均属于本公开的保护范围。

另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合。为了避免不必要的重复，本公开对各种可能的组合方式不再另行说明。

此外，本公开的各种不同的实施方式之间也可以进行任意组合，只要其不违背本公开的思想，其同样应当视为本公开所公开的内容。