内存泄露
原因
1、malloc/new申请的内存没有主动释放
2、new与free混用,malloc与delete混用
3、使用new开辟数组时,delete忘记加[]
4、类的析构函数没有定义为虚函数
排查
查内存占用情况
free
vargrind工具
- 应用环境:Linux
- 编程语言:C/C++
- 使用方法: 编译时加上-g选项,如 gcc -g filename.c -o filename,使用如下命令检测内存使用情况:
- 结果输出:#valgrind --tool=memcheck --leak-check=yes --show-reachable=yes ./filename,就会看到内存使用报告
- 设计思路:根据软件的内存操作维护一个有效地址空间表和无效地址空间表(进程的地址空间)
- 优缺点:能够检测:
使用未初始化的内存 (Use of uninitialised memory)
使用已经释放了的内存 (Reading/writing memory after it has been free’d)
使用超过malloc分配的内存空间(Reading/writing off the end of malloc’d blocks)
对堆栈的非法访问> (Reading/writing inappropriate areas on the stack)
申请的空间是否有释放 (Memory leaks – where pointers to malloc’d blocks are lost forever)
malloc/free/new/delete申请和释放内存的匹配(Mismatched use of malloc/new/new [] vs free/delete/delete [])
src和dst的重叠(Overlapping src and dst pointers in memcpy() and related functions)
重复free
Tcmalloc
Tcmalloc为google 编写的开源内存组件,此组件有2个功效:
- 是使用自己的内存管理,可以替换ulibc或者glibc的内存
- 可以探测HEAP内存泄漏,当然还有其他很强大的功能,本文只讲述内存泄漏的排查。
-
设置环境变量:
export LD_PRELOAD=/home/dofs_core/server/lib/libtcmalloc.so -
运行程序:
HEAPPROFILE=/model/tcmalloc/hicore HEAP_PROFILE_ALLOCATION_INTERVAL=1073741824 ./hicore &
第一个参数是生成的heap的文件名以hicore开头命名、每隔1G写一次dump一次写heap文件
- 用pprof分析heap文件:
(1)、/model/tcmalloc/目录中会生成很多heap文件,然后用pprof将heap文件收获的堆栈信息输出到txt文档中进行查看:./pprof --lib_prefix=/opt/rockchip/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/libc/lib64,/opt/rockchip/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/lib64,./lib --text --lines ./hicore ./hicore.0017.heap > ./text_0017.txt
(命令样式:./pprof --text ./进程名 heap文件名(这个文件可能会生成很多) > 输出的txt文档名)
上图为pprof分析输出的文本图,可通过对上图的内存申请大小进行分析排查,可定位内存泄漏问题,并能定位到源码中的位置。
内存越界
排查
gdb调试
vargrind
能够检查出来内存越界和泄露
TTP版本
core dump
-
查看当前系统是否已开启core文件记录
ulimit -c
如果结果是0说明尚未开启,需要进行设置
-
开启core文件记录
ulimit -c 100 单位是block
ulimit -c unlimited 表示没有限制core文件大小
- 设置生成的core文件路径, 以及core文件命名格式
查看当前core文件存放路径及格式:cat /proc/sys/kernel/core_pattern
- 设置core文件存访路径:
echo "/home/liang/coredump_test/core_%e.%p.%t" > /proc/sys/kernel/core_pattern
%p 进程id
%u 用户id
%g 用户组id
%s 导致产生core的信号
%t core文件生成时时间
%h 主机名
%e 导致产生core的命令名(可执行文件名)
注:以上设置可以放在启动配置中。
- 代码测试生成coredump文件
int main(int argc, char *argv[])
{
int *p = 0;
*p = 100;
return 0;
}
编译时需要添加上-g参数:gcc main.c -o main -g
- 使用gdb查看core文件
gdb ./main core_main.30884.1646125360 ——gdb 对应的可执行文件对应的coredump文件
从信息中可直接看出是源码main.c第4行,*p = 100;直接导致core文件。