目錄
一、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)