目录
一、mtrace 命令
$ gcc test.c -o test -g
$ ./test
$ mtrace test trace.log
1、函数接口
#include <mcheck.h>
void mtrace(void);
void muntrace(void);
mtrace 用于开启内存使用记录,muntrace用于取消内存使用记录。
内存使用情况记录到一个文件,值由环境变量:MALLOC_TRACE决定。
2、测试程序
#include <stdlib.h>
#include <stdio.h>
#include <mcheck.h>
int main(int argc, char **argv)
{
// 设置环境变量 MALLOC_TRACE 为当前目录下的trace.log文件,运行后生成trace.log文件,1是覆盖操作
setenv("MALLOC_TRACE", "trace.log", 1);
// 开启内存追踪
mtrace();
char * p = malloc(100);
free(p);
p = malloc(1000);
// 关闭内存追踪
muntrace();
return 0;
}
(1)编译 test.c
$ gcc test.c -o test -g
加上 -g
参数,在程序中记录调试信息。是为了后面进行程序地址转换为代码文件位置。
(2)运行 ./test,产生 trace.log 文件
$ ./test
运行之后,会在当前目录下产生 trace.log 文件
(3)查看 trace.log 文件
$ cat trace.log
= Start
@ ./test:[0x40070c] + 0x11bf4b0 0x64
@ ./test:[0x40071c] - 0x11bf4b0
@ ./test:[0x400726] + 0x11bf520 0x3e8
= End
@ 程序名称:[内存分配调用的地址] +/- 操作的内存地址 部分参数
+ 表示分配;- 表示释放
(4)使用 mtrace
命令来检查是否存在内存泄漏
mtrace 命令是 glibc-utils 的工具,是一个 perl 脚本文件,通过调用 addr2line 命令来进行解析代码文件位置。如果无该命令,可以安装 glibc-utils 来安装该命令。mtrace 函数是通过修改 malloc_hook 等内存操作接口的回调来实现记录内存使用的。
$
mtrace test trace.log
Memory not freed:
-----------------
Address Size Caller
0x00000000011bf520 0x3e8 at /home/mtracetest/test.c:17
结果表明,在 /home/mtracetest/test.c:17 存在内存泄漏。
3、函数地址返回
gcc 有一个内置的函数,可以用于返回本函数将要返回的地址。
void * __builtin_return_address (unsigned int level);
返回的是处于 level 级堆栈的地址。 level 为 0 表示本函数返回的地址,为 1 表示本函数的上一个函数返回的地址,依次类推。
#include <stdio.h>
int test(int argc, char **argv)
{
void *ret = __builtin_return_address(0);
printf("%p\n", ret - 1);
void *caller = __builtin_frame_address(0);
printf("%p\n", caller);
return 0;
}
int main(int argc, char **argv)
{
test(argc, argv);
return 0;
}
内置函数返回的是本函数返回的地址,是函数调用的下一条语句,所以使用 ret - 1
来记录函数被调用地址。
mtrace 采用 malloc_hook + return_addr 这两个机制来实现的。
mtrace 会记录所有的分配、释放,包括所有的模块、线程。内存使用记录必将很多,所以官方推荐使用 SIGUSR1或SIGUSR2 来进行开启和关闭内存记录功能。
从 mtrace 记录和分析结果可以看到,内存记录日志只记录到 malloc 层面。而实际项目开发时,很多接口都是封装多层才会实际调用到 malloc,对于上面几层的地址,mtrace 没有记录。而上面几层的调用关系才是追踪内存泄漏问题的关键所在。所以在实际开发的项目中,使用 mtrace 不是一个特别好的方法。这里推荐使用 valgrind 工具进行跑流程的方式追踪内存泄漏。如果想要自己记录内存使用情况,可以考虑以下两种方式:
封装一层内存分配、释放的接口函数来记录内存使用情况。项目开发时,统一使用这个接口来进行内存管理。适用于项目尚未开始。
使用 malloc_hook 的方式进行记录,项目代码可以不变。适合于项目已经比较庞大了。
二、valgrind 工具
1、下载
$ sudo apt-get install valgrind
2、查看
$ valgrind --tool=memcheck --leak-check=full --trace-children=yes ./test
==8994== Memcheck, a memory error detector
==8994== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8994== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==8994== Command: ./test
==8994==
fun hello
==8994==
==8994== HEAP SUMMARY:
==8994== in use at exit: 519 bytes in 3 blocks
==8994== total heap usage: 6 allocs, 3 frees, 1,142 bytes allocated
==8994==
==8994== 2 bytes in 1 blocks are definitely lost in loss record 1 of 3
==8994== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8994== by 0x4006D3: fun (test.c:8)
==8994== by 0x40073B: main (test.c:24)
==8994==
==8994== 5 bytes in 1 blocks are definitely lost in loss record 2 of 3
==8994== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8994== by 0x40072D: main (test.c:23)
==8994==
==8994== LEAK SUMMARY:
==8994== definitely lost: 7 bytes in 2 blocks
==8994== indirectly lost: 0 bytes in 0 blocks
==8994== possibly lost: 0 bytes in 0 blocks
==8994== still reachable: 512 bytes in 1 blocks
==8994== suppressed: 0 bytes in 0 blocks
==8994== Reachable blocks (those to which a pointer was found) are not shown.
==8994== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==8994==
==8994== For counts of detected and suppressed errors, rerun with: -v
==8994== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)