CN113886114B

CN113886114B - 一种内存泄漏的定位方法

Info

Publication number: CN113886114B
Application number: CN202111029601.1A
Authority: CN
Inventors: 何俭飞
Original assignee: Shanghai Hongji Information Technology Co Ltd
Current assignee: Shanghai Hongji Information Technology Co Ltd
Priority date: 2021-09-03
Filing date: 2021-09-03
Publication date: 2023-09-01
Anticipated expiration: 2041-09-03
Also published as: CN113886114A

Abstract

本发明公开了一种内存泄漏的定位方法，包括以下步骤：初步缩小内存泄漏的范围，定位到某个模块，通过控制变量的操作方式来缩小排查范围；寻找此模块内所有申请堆内存的地方；在找到的所有申请堆内存的地方上扩大欲申请的内存大小，加上特殊的魔术字；编译，运行进程；采用top命令观察对应进程的内存增涨情况，且记录到日志中；分析日志，观察内存增涨的规律，对应魔术字，定位泄漏点。本发明不依赖任何第三方工具，可以直接在程序中使用堆内存申请的地方进行操作，通过在内存申请处扩大欲申请的内存大小，加上特殊的魔术字，从而在进程运行起来后，通过观察内存的增涨变化，确定泄漏点所在，具有普遍适用性。

Description

一种内存泄漏的定位方法

技术领域

本发明涉及通信技术领域，具体是指一种内存泄漏的定位方法。

背景技术

在进行应用程序编程时，内存的使用主要有以下几种方式：

(1)全局变量：位于代码段中，分配一次，生命周期为整个应用程序生命周期；

(2)栈内存：位于栈中，系统自动维护，即时申请，即时释放；

(3)堆内存：位于堆中，开发人员自己申请，自己释放；

上述三种内存使用方式中，一旦申请了内存，但是忘记了释放，就会产生内存泄漏的问题。其中，前两种方式不会产生内存泄漏，第三种会产生。

第三种也是最普遍的内存泄漏问题，一旦产生内存泄漏，长时间下去，系统会触发OOM机制杀掉内存占用过多的进程(一般就是由于内存泄漏产生的)，导致服务中断。

目前稍成规模的软件系统中，堆内存是不可避免要使用的，但是内存泄漏问题的发生会严重影响系统的运行。故而在进行编程时，开发人员要严格使用堆内存的操作方式，即一次申请，一次释放，以避免内存泄漏的发生。

当前情况下，一旦发生内存泄漏，基本上都会采用类似于valgrind之类的工具拉起进程进行复现，之后分析日志确定泄漏点，具体操作如下：

1)采用valgrind工具拉起进程进行复现，之后分析对应日志；

2)采用glibc自带的mtrace工具运行进程，之后分析对应日志；

3)采用自定义内存分配器进行统计，之后分析统计数据；

4)采用gcc的wrapper机制，替换malloc，运行进程，之后分析统计数据。

上述方法具有以下缺点：

1)采用valgrind工具拉起进程进行复现，之后分析对应日志：此方法为最常用的方法，编译出对应系统的valgrind工具，然后使用valgrind工具拉起会产生内存泄漏的进程，最后分析valgrind产生的日志，从而确定泄漏点。但是，许多系统下不能编译出对应的valgrind工具，或者编译非常麻烦，此时要想获取valgrind就不是很便捷。

2)采用glibc自带的mtrace工具运行进程，之后分析对应日志：一般堆内存管理均采用glibc自带的malloc函数，glibc库提供了对应的内存申请、释放记录工具mtrace。可以修改应用程序，引入mtrace工具，然后运行进程，之后分析mtrace工具产生的日志。目前，除了glibc的内存分配器外，还有其他内存分配器，例如jemalloc，一旦不使用glibc的内存分配器，mtrace也就无法使用了。

3)采用自定义内存分配器进行统计，之后分析统计数据：多数情况下，我们可以将系统的内存分配器函数进行封装，加上统计信息，然后使用堆内存时采用我们自定义的封装后的分配器函数，运行进程后，对统计信息进行分析，即可定位泄漏点。但是，由于各种原因(例如开发人员习惯)，应用程序内可能不会全部使用封装后的分配器，这样就无法对所有堆内存使用进行统计分析了。

4)采用gcc的wrapper机制，替换malloc，运行进程，之后分析统计数据：常用编译器为gcc，其提供了wrapper机制，我们可以单独封装系统的内存分配器，然后在编译时采用wrapper机制替换掉系统自带的内存分配器。但是，除了gcc编译器之外，还有其他编译器，其可能没有提供这样的机制。

所以，一种定位、分析应用程序产生内存泄漏原因的方法成为人们亟待解决的问题。

发明内容

本发明的目的是通过在内存申请处扩大欲申请的内存大小，加上特殊的魔术字，从而在进程运行起来后，通过观察内存的增涨变化，确定泄漏点所在。

为实现上述目的，本发明提供的技术方案为：一种内存泄漏的定位方法，包括以下步骤：

步骤1、初步缩小内存泄漏的范围，定位到某个模块，通过控制变量的操作方式来缩小排查范围；

步骤2、寻找此模块内所有申请堆内存的地方：一旦通过排查缩小了内存泄漏的范围，定位到某个模块后，就可以分析此模块的逻辑，找出其申请堆内存的所有地方；

步骤3、在找到的所有申请堆内存的地方上扩大欲申请的内存大小，加上特殊的魔术字；

步骤4、编译，运行进程：按照步骤3中所述的方式修改好代码后，重新编译代码，得到新的程序，并运行新的程序，同时使用之前的配置、环境进行操作复现；

步骤5、采用top命令观察对应进程的内存增涨情况，且记录到日志中；

步骤6、分析日志，观察内存增涨的规律，对应魔术字，定位泄漏点：采用Linux下的文本处理工具对日志文件进行处理，观察内存增长的规律，通过增长量的大小和之前扩充的魔术字大小比较，即可判断出内存泄漏的地方。

作为改进，所述步骤1中内存泄漏的原因包括修改配置导致内存泄漏，处理业务流量导致内存泄漏，内部的定时器、日志导致内存泄漏；

作为改进，所述步骤3中的魔术字要求大小各不相同。

作为改进，所述步骤5中的top命令为Linux下的用于观察系统进程运行情况的工具，其也能观察进程的内存使用情况，重点是输出结果的RES列，其表示进程所使用的物理内存大小。

作为改进，所述步骤6中的文本处理工具包括cat、awk、sed、grep、sort。

本发明与现有技术相比的优点在于：本发明不用依赖于类似valgrind之类的工具，也不依赖具体的内存分配器，可以直接在程序中使用堆内存申请的地方进行操作，通过在内存申请处扩大欲申请的内存大小，加上特殊的魔术字，从而在进程运行起来后，通过观察内存的增涨变化，确定泄漏点所在，具有普遍适用性。

具体实施方式

下面对本发明一种内存泄漏的定位方法做进一步的详细说明。

一种内存泄漏的定位方法，包括以下步骤：

步骤1、初步缩小内存泄漏的范围，定位到某个模块：一般地，当观察到某个进程的内存使用增长不正常时，可以分析该进程所承载的业务，确定是修改配置导致，还是处理业务流量导致，亦或是内部的定时器、日志等所导致；此时可以通过控制变量的操作方式来缩小排查范围；

步骤3、在找到的所有申请堆内存的地方上扩大欲申请的内存大小，加上特殊的魔术字：即在怀疑的模块中申请堆内存的地方，加上大小不一的魔术字，比如，申请64K内存的地方，变成64K+1M，申请256K的地方，变成256K+3M等；此处扩大内存的申请大小，一旦真正存在内存泄漏时，非常便于观察；

步骤5、采用top命令观察对应进程的内存增涨情况，且记录到日志中：top命令为Linux下的用于观察系统进程运行情况的工具，其也能观察进程的内存使用情况，重点是输出结果的RES列，其表示进程所使用的物理内存大小；记录到日志中，是便于采用Linux下的文本处理工具进行分析，探究内存增长规律；

步骤6、分析日志，观察内存增涨的规律，对应魔术字，定位泄漏点：采用Linux下的文本处理工具cat、awk、sed、grep、sort等对日志文件进行处理，观察内存增长的规律，通过增长量的大小和之前扩充的魔术字大小比较，即可判断出内存泄漏的地方；例如，增长量5M比较多，那么上述修改代码处，采用5M魔术字的申请处就是一处内存泄漏点；这是因为，当时申请了5M多的内存，后续也观察到了这5M多的内存增长量，而这5M多的内存增长量又没有归还给系统(归还系统后，内存使用大小会变小)，那只能是申请了但没有释放，即产生了内存泄漏。

本发明一种内存泄漏的定位方法的具体实施过程如下：

1)准备示例程序：memory_leak_test.c(不含行号)；

2)编译上述程序：产生可执行文件memory_leak_test；

gcc-g3-O0-o memory_leak_test memory_leak_test.c

3)运行进程：

./memory_leak_test

4)采用top命令观察对应进程的内存增涨情况，且记录到日志中：

top-d 1-b-p`pidof memory_leak_test`2>&1|tee-a origin_data.log

5)处理日志：

cat origin_data.log|sed-n'/load/p'|awk-F”'{printf$3"\n"}'|awk'{printFNR","$0}'>>time_data.log

cat origin_data.log|sed-n'/memory/p'|awk-F”'{printf$6"\n"}'|awk'{print FNR","$0}'>>memory_data.log

awk-F',”NR＝＝FNR{a[$1]＝$2}NR>FNR{print$2,a[$1]}'memory_data.logtime_data.log|awk'{print FNR,$0}'>time_memory_data.log

6)分析日志，观察内存增涨的规律，对应魔术字，定位泄漏点：

7)输出解释：针对日志time_memory_data.log

第一列：序号，top命令采集的次数；

第二列：时间，top命令采集的时间；

第三列：内存，top命令集采内存泄漏进程的内存使用情况，单位为KB；

对于第三列，采用下一行内存使用量减去上一行内存使用量的方式，得出两次采集的内存增涨情况，经过计算、筛选后如表1所示：

表1：两次采集的内存增涨计算、筛选表

从表1中可以看出，上下两行的差值中，存在5212(5M)、3100(3M)、2904(3M)、3104(3M)几组数据，且3M的较多，此时就能定位到泄漏点为魔术字3M所在的内存申请处，即代码的25行附近。

以上对本发明及其实施方式进行了描述，上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，如果本领域的普通技术人员受其启示，在不脱离本发明创造宗旨的情况下，不经创造性的设计出与该技术方案相似的结构方式及实施例，均应属于本发明的保护范围。

Claims

1.一种内存泄漏的定位方法，其特征在于：包括以下步骤：

2.根据权利要求1所述的一种内存泄漏的定位方法，其特征在于：所述步骤1中内存泄漏的原因包括修改配置导致内存泄漏，处理业务流量导致内存泄漏，内部的定时器、日志导致内存泄漏。

3.根据权利要求1所述的一种内存泄漏的定位方法，其特征在于：所述步骤3中的魔术字要求大小各不相同。

4.根据权利要求1所述的一种内存泄漏的定位方法，其特征在于：所述步骤5中的top命令为Linux下的用于观察系统进程运行情况的工具，其也能观察进程的内存使用情况，重点是输出结果的RES列，其表示进程所使用的物理内存大小。

5.根据权利要求1所述的一种内存泄漏的定位方法，其特征在于：所述步骤6中的文本处理工具包括cat、awk、sed、grep、sort。