當前位置：首頁 > 编程语言 > c/c++ >内容正文

c/c++

使用LeakTracer检测android NDK C/C++代码中的memory leak

發布時間：2024/4/11 c/c++ 26 豆豆

生活随笔收集整理的這篇文章主要介紹了使用LeakTracer检测android NDK C/C++代码中的memory leak 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

Memory issue是C/C++開發中比較常遇到，經常帶給人比較大困擾，debug起來又常常讓人無從下手的一類問題，memory issue主要又分為memory leak，野指針，及其它非法訪問等問題。在android平臺上，使用NDK開發C/C++ code，由于沒有其它成熟的平臺，如Windows，Linux等上面可用的許多工具，使得memory issue變得更為棘手。

問題存在，那解決辦法總是有的。比較好用又可靠的一個debug android NDK C/C++ code memory issue的辦法就是，把android NDK的C/C++代碼，移植到其它平臺上并運行起來，然后使用那個平臺下的工具，比如Linux desktop Ubuntu等，我們就可以使用諸如valgrind等異常強大的工具了，StackOverflow上有一道題Detect memory leak in android native code，其中一個答案總結了一些memory leak的檢測工具。特別是android和Linux desktop都使用相同的linux kernel，使得移植這項工作并不是特別復雜。

當然還有另外一種解決問題的方法，那就是把傳統上其它平臺的一些工具給移植到android上來使用，比如valgrind就可以用在android上，但只是不太方便而已。而這里，我們就是將LeakTracer這一linux平臺上常用的memory leak檢測工具給移植到android上來使用。

LeakTracer的下載、編譯

LeakTracer official site。LeakTracer github repo。可以通過git clone將LeakTracer的code download下來，這個項目的結構如下：

helpers目錄下是一些輔助腳本，用來幫助分析產生的trace文件的；libleaktracer目錄下是主要用于trace memory leak的代碼，也是需要我們集成進我們項目的代碼；test目錄下的test 可以參考來對LeakTracer進行集成；README則說明了使用LeakTracer的方法。

可以以3種方式來使用使用LeakTracer：

將自己的程序與libleaktracer.a進行鏈接，也就是將自己的程序一個靜態鏈接庫libleaktracer.a進行鏈接，我們知道靜態鏈接是會將庫的代碼揉進我們自己項目的目標代碼so中的。

將自己的程序與libleaktracer.so進行鏈接。需要將-lleaktracer選項做為鏈接命令的第一個選項。當對程序執行"objdump -p"時，應該能看到leaktracer.so是Dynamic Section的第一個NEEDED entry才對。
通過LD_PRELOAD環境變量來使得libleaktracer.so在任何其它動態鏈接庫之前被加載，然后不需要對程序做任何的更改，還可以通過環境變量來對LeakTracer的行為進行定制。

這三種方法中的第一種，可以通過將libleaktracer的code復制到我們的項目中，與我們項目中的其它代碼一起編譯來實現。第二種和第三種都是想要使得leaktracer.so成為程序第一個被加載的library，我們知道，在android上zygote在fork一個應用進程時，也會連帶將它之前加載的動態鏈接庫一并傳給我們的應用進程，這項任務看起來似乎并不是太容易實現。

這里我們就將libleaktracer的代碼復制進我們的項目中，放在jni/3rd/目錄下。然后修改我們的jni的Android.mk，主要改動內容為在適當的位置增加如下內容：

LOCAL_C_INCLUDES += $(LOCAL_PATH)/3rd/libleaktracer/include/ LOCAL_SRC_FILES += 3rd/libleaktracer/src/AllocationHandlers.cpp \3rd/libleaktracer/src/MemoryTrace.cpp

同時呢，還要修改jni的Application.mk，增加如下內容：

APP_OPTIM := debug

這樣才能在編譯的時候，帶進更多的debug信息進目標文件。

進行到這里，進行編譯，一切都ok。但想要通過Eclipse啟動運行app則遇到了麻煩。Eclipse檢測到libleaktracer下有個LeakTracerC.c文件libleaktracer/src/LeakTracerC.c，這個文件主要用于純C的項目，而我們這里是一個C++的項目，因而并不會用到這個文件。但Eclipse檢測到這個C文件中，卻用了C++的語法，因而會標示語法錯誤。我們可以將這個文件直接刪掉或者將它的后綴改為cpp來解決問題。

LeakTracer的集成

要使用LeakTracer的最后一公里，也就是啟動trace，并在結束trace時，將檢測到的memory leak信息寫入文件。參考LeakTracer/tests/test.cc的code，我們可以在我們自己的library的初始化函數中加入如下的code來啟動trace：

// starting monitoring allocationsleaktracer::MemoryTrace::GetInstance().startMonitoringAllThreads();

然后在結束時的銷毀函數中加入如下的code來將memory leak信息寫入文件：

leaktracer::MemoryTrace::GetInstance().stopAllMonitoring();Poco::Thread::sleep(3000);LOGI("To writeLeaksToFile %s.", "/sdcard/leaks.out");leaktracer::MemoryTrace::GetInstance().writeLeaksToFile("/sdcard/leaks.out");

這個地方為什么要sleep呢？這是為了等待我們library的其它資源的釋放，比如一些線程握有的資源等，以減少LeakTracer的false alarm。

集成結束，開始運行來檢測memory leak。我們的app剛一運行起來，就發生了一個SIGSEGV的crash：

看上去是一個空指針，這空指針產生略詭異。我們試圖通過在System.loadLibrary()前加一段sleep 5s的代碼，并用Eclipse的"Debug As"的"Android Native Application"運行程序，以期能獲得更多空指針發生的位置的信息，但似乎并不能獲得更多這一crash發生的backtrace的信息。

但不難想到，這個空指針很可能發生在libleaktracer初始化的代碼里。這個library并沒有太多的code，我們可以將這個library初始化相關的所有函數的開始結束處都加上log，來追查空指針到底發生在什么地方。主要包括如下的這些函數：

MemoryTrace::init_no_alloc_allowed() MemoryTrace::init_full_from_once() MemoryTrace::init_full() int MemoryTrace::Setup(void) void MemoryTrace::MemoryTraceOnInit(void)void* operator new(size_t size) void* operator new[] (size_t size) void operator delete (void *p) void operator delete[] (void *p) void *malloc(size_t size) void free(void* ptr) void* realloc(void *ptr, size_t size) void* calloc(size_t nmemb, size_t size)

加完了log，再次運行我們的程序，這次能夠看到這樣的一些信息：

可以看到，這個crash發生在libleaktracer的malloc函數中，調用棧為operator new() -> MemoryTrace::Setup(void) -> MemoryTrace::init_full_from_once() -> MemoryTrace::init_full() -> malloc()。

malloc的代碼如下：

void *malloc(size_t size) {void *p;leaktracer::MemoryTrace::Setup();leaktracer::MemoryTrace::GetInstance().InternalMonitoringDisablerThreadUp();p = LT_MALLOC(size);leaktracer::MemoryTrace::GetInstance().InternalMonitoringDisablerThreadDown();leaktracer::MemoryTrace::GetInstance().registerAllocation(p, size, false);return p; }

我們就繼續加log，在任意兩行之間都加上log。這次運行我們的程序，可以看到這樣的一些log輸出：

由此不難看出，正是如下的這一行訪問了空指針：

p = LT_MALLOC(size);

LT_MALLOC是一個宏(jni/3rd/libleaktracer/include/ObjectsPool.hpp)，是一個函數指針的別名：

#define LT_MALLOC (*lt_malloc) #define LT_FREE (*lt_free) #define LT_REALLOC (*lt_realloc) #define LT_CALLOC (*lt_calloc)

函數指針則定義在jni/3rd/libleaktracer/src/AllocationHandlers.cpp中：

void* (*lt_malloc)(size_t size); void (*lt_free)(void* ptr); void* (*lt_realloc)(void *ptr, size_t size); void* (*lt_calloc)(size_t nmemb, size_t size);

函數指針則定義在jni/3rd/libleaktracer/src/AllocationHandlers.cpp中：

void* (*lt_malloc)(size_t size); void (*lt_free)(void* ptr); void* (*lt_realloc)(void *ptr, size_t size); void* (*lt_calloc)(size_t nmemb, size_t size);

這些個函數指針都通過結構體數組static libc_alloc_func_t libc_alloc_funcs，在MemoryTrace::init_no_alloc_allowed()中進行初始化( jni/3rd/libleaktracer/src/MemoryTrace.cpp )：

typedef struct {const char *symbname;void *libcsymbol;void **localredirect; } libc_alloc_func_t;static libc_alloc_func_t libc_alloc_funcs[] = {{ "calloc", (void*)__libc_calloc, (void**)(&lt_calloc) },{ "malloc", (void*)__libc_malloc, (void**)(&lt_malloc) },{ "realloc", (void*)__libc_realloc, (void**)(&lt_realloc) },{ "free", (void*)__libc_free, (void**)(&lt_free) } };void MemoryTrace::init_no_alloc_allowed() {libc_alloc_func_t *curfunc;unsigned i;for (i=0; i<(sizeof(libc_alloc_funcs)/sizeof(libc_alloc_funcs[0])); ++i) {curfunc = &libc_alloc_funcs[i];if (!*curfunc->localredirect) {if (curfunc->libcsymbol) {*curfunc->localredirect = curfunc->libcsymbol;} else {*curfunc->localredirect = dlsym(RTLD_NEXT, curfunc->symbname);}}}

MemoryTrace::init_no_alloc_allowed()中進行初始化的這段代碼，主要是找到系統本來的那組分配/釋放內存的函數的地址，并保存在lt_malloc這一組函數指針中。

android的標準C庫中，并沒有__libc_malloc這一組符號，因而lt_malloc的值應該來自于dlsym(RTLD_NEXT, curfunc->symbname)。

我們知道dlsym()函數可以與dlopen()配合，動態加載一個動態鏈接庫，并獲取里面的函數指針。dlsym()函數接收兩個參數，一個是dlopen()打開的動態鏈接庫的handle，另一個符號名。動態鏈接庫的handle也可以不來自于dlopen()，而是RTLD_DEFAULT和RTLD_NEXT這兩個特殊的值，其中前者表示從當前應用加載的第一個動態鏈接庫開始查找符號地址，而后者則表示從當前so的下一個so開始查找符號地址。

看到這里，也就不難理解為何需要先加載libleaktracer了。總結一下，有兩個原因，一是在動態鏈接時，程序對于分配/釋放內存的函數的調用能鏈接到libleaktracer的實現，二是這里能夠找到系統的那組分配/釋放內存的函數。

但在android平臺上，我們是沒有辦法讓libleaktracer的code早于其它所有的動態鏈接庫加載的，因而我們需要將這里的**RTLD_NEXT給替換成RTLD_DEFAULT**，以便于能夠找到系統的那組內存分配/釋放函數的地址。

至此libleaktracer的初始化過程終于可以正常的執行了。內存的分配/釋放函數調用的頻率實在是太高了，因而去掉剛剛加的那些log，準備迎接下一步的挑戰。

但運行起來之后，又出現了crash了。

這次倒是可以通過Eclipse的"Debug As"的"Android Native Application"抓到發生crash的整個backtrace：

MemoryTrace::storeAllocationStack()的code如下：

inline void MemoryTrace::storeAllocationStack(void* arr[ALLOCATION_STACK_DEPTH]) {unsigned int iIndex = 0; #ifdef USE_BACKTRACEvoid* arrtmp[ALLOCATION_STACK_DEPTH+1];iIndex = backtrace(arrtmp, ALLOCATION_STACK_DEPTH + 1) - 1;memcpy(arr, &arrtmp[1], iIndex*sizeof(void*)); #elsevoid *pFrame;// NOTE: we can't use "for" loop, __builtin_* functions// require the number to be known at compile timearr[iIndex++] = ( (pFrame = __builtin_frame_address(0)) != NULL) ? __builtin_return_address(0) : NULL; if (iIndex == ALLOCATION_STACK_DEPTH) return;arr[iIndex++] = (pFrame != NULL && (pFrame = __builtin_frame_address(1)) != NULL) ? __builtin_return_address(1) : NULL; if (iIndex == ALLOCATION_STACK_DEPTH) return;arr[iIndex++] = (pFrame != NULL && (pFrame = __builtin_frame_address(2)) != NULL) ? __builtin_return_address(2) : NULL; if (iIndex == ALLOCATION_STACK_DEPTH) return;arr[iIndex++] = (pFrame != NULL && (pFrame = __builtin_frame_address(3)) != NULL) ? __builtin_return_address(3) : NULL; if (iIndex == ALLOCATION_STACK_DEPTH) return;arr[iIndex++] = (pFrame != NULL && (pFrame = __builtin_frame_address(4)) != NULL) ? __builtin_return_address(4) : NULL; if (iIndex == ALLOCATION_STACK_DEPTH) return;arr[iIndex++] = (pFrame != NULL && (pFrame = __builtin_frame_address(5)) != NULL) ? __builtin_return_address(5) : NULL; if (iIndex == ALLOCATION_STACK_DEPTH) return;arr[iIndex++] = (pFrame != NULL && (pFrame = __builtin_frame_address(6)) != NULL) ? __builtin_return_address(6) : NULL; if (iIndex == ALLOCATION_STACK_DEPTH) return;arr[iIndex++] = (pFrame != NULL && (pFrame = __builtin_frame_address(7)) != NULL) ? __builtin_return_address(7) : NULL; if (iIndex == ALLOCATION_STACK_DEPTH) return;arr[iIndex++] = (pFrame != NULL && (pFrame = __builtin_frame_address(8)) != NULL) ? __builtin_return_address(8) : NULL; if (iIndex == ALLOCATION_STACK_DEPTH) return;arr[iIndex++] = (pFrame != NULL && (pFrame = __builtin_frame_address(9)) != NULL) ? __builtin_return_address(9) : NULL; #endif// fill remaining spacesfor (; iIndex < ALLOCATION_STACK_DEPTH; iIndex++)arr[iIndex] = NULL; }

可以看到，這個函數主要是利用gcc的內置函數builtin_frame_address()和builtin_return_address()獲取一次內存分配發生的整個的callstack。由于對內存訪問的權限限制的原因，而會發生SIGSEGV錯誤。但又不是在第一次調用這些內置函數時發生的crash。那就先把保存的callstack的深度調淺一點好了，比如把ALLOCATION_STACK_DEPTH的值改為3。這倒是不crash了，但每次獲得的backtrace都只有一層，而且每個backtrace都一樣，這些信息真是毫無用處，它們都指向libleaktracer的malloc。

看來通過gcc的內置函數builtin_frame_address()和builtin_return_address()獲取backtrace這條路是行不同了。那android平臺上native層到底有沒有其它可以獲取backtrace的方法呢？答案當然是，有～，而且那個接口比gcc的內置函數還有好用許多。這個好用的接口就是_Unwind_Backtrace**()**。include標準庫頭文件#include <unwind.h>就可以使用_Unwind_Backtrace()了，這個函數的原型如下：

typedef struct _Unwind_Context _Unwind_Context;/* @@@ Use unwind data to perform a stack backtrace. The trace callbackis called for every stack frame in the call chain, but no cleanupactions are performed. */typedef _Unwind_Reason_Code (*_Unwind_Trace_Fn) (_Unwind_Context *, void *);_Unwind_Reason_Code _Unwind_Backtrace(_Unwind_Trace_Fn,void*);

_Unwind_Backtrace()接收兩個參數，一個是_Unwind_Reason_Code () (_Unwind_Context , void *)類型的函數指針_Unwind_Trace_Fn，另外一個是userdata，會被作為每次調用 _Unwind_Trace_Fn的第二個參數傳入。 _Unwind_Backtrace()的執行，會針對調用鏈中的每一級stack frame調用trace callback _Unwind_Trace_Fn，在這個callback的實現中，我們可以保存stack frame的信息。

我們重寫MemoryTrace::storeAllocationStack()函數：

struct TraceHandle {void **backtrace;int pos; };_Unwind_Reason_Code Unwind_Trace_Fn(_Unwind_Context *context, void *hnd) {struct TraceHandle *traceHanle = (struct TraceHandle *) hnd;_Unwind_Word ip = _Unwind_GetIP(context);if (traceHanle->pos != ALLOCATION_STACK_DEPTH) {traceHanle->backtrace[traceHanle->pos] = (void *) ip;++traceHanle->pos;return _URC_NO_REASON;}return _URC_END_OF_STACK; }// stores allocation stack, up to ALLOCATION_STACK_DEPTH // frames void MemoryTrace::storeAllocationStack(void* arr[ALLOCATION_STACK_DEPTH]) {unsigned int iIndex = 0;TraceHandle traceHandle;traceHandle.backtrace = arr;traceHandle.pos = 0;_Unwind_Backtrace(Unwind_Trace_Fn, &traceHandle);// fill remaining spacesfor (iIndex = traceHandle.pos; iIndex < ALLOCATION_STACK_DEPTH; iIndex++)arr[iIndex] = NULL; }

在這里我們通過_Unwind_Backtrace**()來獲得調用棧。系統還提供了_Unwind_GetIP**()用來幫助我們獲取每一個stack frame的指令指針IP。

在我們的library銷毀時保存trace信息到文件中，從設備上將該文件/sdcard/leaks.out pull出來，可以看到如下的這樣一些內容：

# LeakTracer report diff_utc_mono=1448719075.832670 leak, time=9077.889212, stack=0xa3241568 0xa323fac0 0xa323fdd4 0xa321407c 0xa3213fe8, size=12, data=..i.X.i...j. leak, time=9077.889945, stack=0xa3241568 0xa323fac0 0xa323fdd4 0xa32b8a94 0xa32ba1b8, size=27, data=.mi.8A......42.62.105.193.j leak, time=9077.889151, stack=0xa3241568 0xa323fac0 0xa323fdd4 0xa32b8a94 0xa32b96e4, size=84, data=G...G.......{"size":1885076,"spd":1.23937e+06,"tim leak, time=9074.898368, stack=0xa3241568 0xa323fac0 0xa323fdd4 0xa32039ec 0xa3209cec, size=88, data= .0.......i.d.r.......................i........... leak, time=9084.530140, stack=0xa3241568 0xa323fac0 0xa323fdd4 0xa32b8a94 0xa32ba1b8, size=19, data=............ipPriv. leak, time=9088.118207, stack=0xa3241568 0xa323fac0 0xa323fdd4 0xa32b8a94 0xa32b8c68, size=13, data=............. leak, time=9084.530354, stack=0xa3241568 0xa323fac0 0xa323fdd4 0xa31a8e80 0xa31a8bac, size=28, data=....\$j..%j..%j.\"j......$j. leak, time=9084.530232, stack=0xa3241568 0xa323fac0 0xa323fdd4 0xa31ab740 0xa31ab7f4, size=24, data=0A.......#j.H&j..&j..... leak, time=9084.530537, stack=0xa3241568 0xa323fac0 0xa323fdd4 0xa31ab114 0xa3212be4, size=4, data=.._. leak, time=9084.530628, stack=0xa3241568 0xa323fac0 0xa323fdd4 0xa32b8a94 0xa32ba1b8, size=18, data=............ipPub. leak, time=9084.530720, stack=0xa3241568 0xa323fac0 0xa323fdd4 0xa31a8e80 0xa31a8bac, size=28, data=.....%j......&j..$j......$j.

既然有了沒被正確釋放的內存分配時候的backtrace，那就將它們轉換到代碼文件的行數吧。LeakTracer/helpers下的leak-analyze-addr2line工具可以幫我們完成這些。leak-analyze-addr2line的用法如下：

Usage: /usr/bin/leak-analyze-addr2line <PROGRAM> <LEAKFILE>

于是我們輸入如下的命令：

leak-analyze-addr2line /media/data/CorpProjects/git_repos/P2PClient/peerTester/obj/local/armeabi-v7a/libmoretvp2p.so leaks.out

注意這里的so文件的路徑，不是libs/armeabi-v7a下面的那個，那個so中是沒有debug信息的，而是obj/local/armeabi-v7a/下面的。

但執行上面的命令，我們卻只得到了這樣的一些信息：

貌似完全無法得到backtrace對應的代碼行數呢。問題出在哪里了呢？

回頭再看/sdcard/leaks.out中的backtrace，可以看到內存地址都是進程地址空間的絕對地址，動態鏈接庫在每次加載是都可能被映射在進程內存地址空間的不同位置，因而addr2line無法根據符號的地址空間絕對地址轉換到代碼行數也容易理解。難道我們要先通過/proc/[pid]/maps找到我們的動態鏈接庫映射的內存基地址，然后手動算出backtrace每個地址對應的動態鏈接庫內部的偏移地址，再通過addr2line來將內存地址轉換到代碼文件的行號？

這是比較難辦到的：一來許多production的設備，根本不允許我們訪問進程的內存映射/proc/[pid]/maps；二是backtrace的內存地址太多，手動轉要猴年馬月才能賺得完。

看起來只要我們能夠獲取我們的library映射到的內存的基地址，一切問題也就迎刃而解了，但android平臺是否存在這樣的一種方法呢？答案當然是肯定的，這個函數也就是int dladdr(const void addr, Dl_info info)。dladdr()與dlsym()一樣，同在libdl中。

于是我們定義一個靜態的Dl_info結構對象s_P2pSODlInfo，并在MemoryTrace::init_no_alloc_allowed()中，初始化lt_calloc等函數指針的那段code下面加一行對dladdr()的調用：

dladdr((const void*)init_no_alloc_allowed, &s_P2pSODlInfo);LOGI("s_P2pSODlInfo, dli_fbase = %p, dli_fname = %s, dli_saddr = %p, dli_sname = %s",s_P2pSODlInfo.dli_fbase, s_P2pSODlInfo.dli_fname, s_P2pSODlInfo.dli_saddr, s_P2pSODlInfo.dli_sname);

這里我們就通過函數init_no_alloc_allowed的地址來獲得整個library內存映射的基地址。同時修改_Unwind_Backtrace的Unwind_Trace_Fn為如下這樣：

_Unwind_Reason_Code Unwind_Trace_Fn(_Unwind_Context *context, void *hnd) {struct TraceHandle *traceHanle = (struct TraceHandle *) hnd;_Unwind_Word ip = _Unwind_GetIP(context);if (traceHanle->pos != ALLOCATION_STACK_DEPTH) {traceHanle->backtrace[traceHanle->pos] = (void *) (ip - (_Unwind_Word) s_P2pSODlInfo.dli_fbase);++traceHanle->pos;return _URC_NO_REASON;}return _URC_END_OF_STACK; }

將我們通過_Unwind_GetIP()獲得的IP值都減去library 內存映射的基地址。

再次運行我們的程序，產生memory leak的trace文件并pull下來，并用leak-analyze-addr2line工具進行分析，終于可以獲得leak的內存分配時的callstack了，如下面這樣：

Processing "leaks.out" log for "/media/data/CorpProjects/git_repos/P2PClient/peerTester/obj/local/armeabi-v7a/libmoretvp2p.so" Matching addresses to "/media/data/CorpProjects/git_repos/P2PClient/peerTester/obj/local/armeabi-v7a/libmoretvp2p.so" found 165 leak(s) 24 bytes lost in 1 blocks (one of them allocated at 10597.290280), from following call stack:/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/3rd/libleaktracer/src/MemoryTrace.cpp:316/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/3rd/libleaktracer/include/MemoryTrace.hpp:368/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/3rd/libleaktracer/src/AllocationHandlers.cpp:29/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/3rd/json/src/Value.cpp:361/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/3rd/json/src/Value.cpp:368 (discriminator 1) 69 bytes lost in 3 blocks (one of them allocated at 10585.557730), from following call stack:/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/3rd/libleaktracer/src/MemoryTrace.cpp:316/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/3rd/libleaktracer/include/MemoryTrace.hpp:368/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/3rd/libleaktracer/src/AllocationHandlers.cpp:29libgcc2.c:?libgcc2.c:? 12 bytes lost in 1 blocks (one of them allocated at 10587.229148), from following call stack:/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/3rd/libleaktracer/src/MemoryTrace.cpp:316/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/3rd/libleaktracer/include/MemoryTrace.hpp:368/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/3rd/libleaktracer/src/AllocationHandlers.cpp:29/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/src/core/PlaySession.cpp:38 (discriminator 7)/media/data/CorpProjects/git_repos/P2PClient/peerTester/jni/src/core/PlaySessionInitializer.cpp:241 (discriminator 3)

可能由于內存釋放的時延等原因，LeakTracer報出來的問題不一定是真正的memory leak，也可能只是false alarm，具體問題還需要根據LeakTracer產生的報告再來做分析。

LeakTracer的設計與實現

這里我們再來分析一下LeakTracer的設計與實現。

LeakTracer主要的設計思路為：

實現一組內存的分配/釋放函數，這組函數的函數原型與系統的那一組完全一樣，讓被trace的library對于內存的分配/釋放函數的調用都鏈接到自己實現的這一組函數中以override掉系統的那組內存/分配釋放函數；

自己實現的這組函數中的內存分配函數記錄分配相關的信息，包括分配的內存的大小，callstack等，并調用系統本來的內存分配函數去分配內存；

自己實現的這組函數中的內存釋放函數則銷毀內存分配的相關記錄，并使用系統的內存釋放函數真正的釋放內存；

在trace結束時，遍歷所有保存的內存分配記錄的信息，并把這些信息保存進文件以供進一步的分析。

LeakTracer實現的用于override系統內存分配/釋放函數的那組函數在jni/3rd/libleaktracer/src/AllocationHandlers.cpp中定義：

void* (*lt_malloc)(size_t size); void (*lt_free)(void* ptr); void* (*lt_realloc)(void *ptr, size_t size); void* (*lt_calloc)(size_t nmemb, size_t size);void* operator new(size_t size) {void *p;leaktracer::MemoryTrace::Setup();p = LT_MALLOC(size);leaktracer::MemoryTrace::GetInstance().registerAllocation(p, size, false);return p; }void* operator new[] (size_t size) {void *p;leaktracer::MemoryTrace::Setup();p = LT_MALLOC(size);leaktracer::MemoryTrace::GetInstance().registerAllocation(p, size, true);return p; }void operator delete (void *p) {leaktracer::MemoryTrace::Setup();leaktracer::MemoryTrace::GetInstance().registerRelease(p, false);LT_FREE(p); }void operator delete[] (void *p) {leaktracer::MemoryTrace::Setup();leaktracer::MemoryTrace::GetInstance().registerRelease(p, true);LT_FREE(p); }/** -- libc memory operators -- **//* malloc* in some malloc implementation, there is a recursive call to malloc* (for instance, in uClibc 0.9.29 malloc-standard )* we use a InternalMonitoringDisablerThreadUp that use a tls variable to prevent several registration* during the same malloc*/ void *malloc(size_t size) {void *p;leaktracer::MemoryTrace::Setup();leaktracer::MemoryTrace::GetInstance().InternalMonitoringDisablerThreadUp();p = LT_MALLOC(size);leaktracer::MemoryTrace::GetInstance().InternalMonitoringDisablerThreadDown();leaktracer::MemoryTrace::GetInstance().registerAllocation(p, size, false);return p; }void free(void* ptr) {leaktracer::MemoryTrace::Setup();leaktracer::MemoryTrace::GetInstance().registerRelease(ptr, false);LT_FREE(ptr); }void* realloc(void *ptr, size_t size) {void *p;leaktracer::MemoryTrace::Setup();leaktracer::MemoryTrace::GetInstance().InternalMonitoringDisablerThreadUp();p = LT_REALLOC(ptr, size);leaktracer::MemoryTrace::GetInstance().InternalMonitoringDisablerThreadDown();if (p != ptr){if (ptr)leaktracer::MemoryTrace::GetInstance().registerRelease(ptr, false);leaktracer::MemoryTrace::GetInstance().registerAllocation(p, size, false);}else{leaktracer::MemoryTrace::GetInstance().registerReallocation(p, size, false);}return p; }void* calloc(size_t nmemb, size_t size) {void *p;leaktracer::MemoryTrace::Setup();leaktracer::MemoryTrace::GetInstance().InternalMonitoringDisablerThreadUp();p = LT_CALLOC(nmemb, size);leaktracer::MemoryTrace::GetInstance().InternalMonitoringDisablerThreadDown();leaktracer::MemoryTrace::GetInstance().registerAllocation(p, nmemb*size, false);return p; }

系統的那組內存分配/釋放函數的函數指針也在這個文件中定義。如我們前面看到的，系統的那組內存分配/釋放函數的函數指針在MemoryTrace::init_no_alloc_allowed()中通過dlsym(RTLD_DEFAULT, curfunc->symbname)進行初始化。

LeakTracer通過leaktracer::MemoryTrace::GetInstance().registerAllocation(p, size, false)記錄每一次內存分配的相關信息：

// adds all relevant info regarding current allocation to map inline void MemoryTrace::registerAllocation(void *p, size_t size, bool is_array) {allocation_info_t *info = NULL;if (!AllMonitoringIsDisabled() && (__monitoringAllThreads || getThreadOptions().monitoringAllocations) && p != NULL) {MutexLock lock(__allocations_mutex);info = __allocations.insert(p);if (info != NULL) {info->size = size;info->isArray = is_array;storeTimestamp(info->timestamp);}}// we store the stack without locking __allocations_mutex// it should be safe enough// prevent a deadlock between backtrave function who are now using advanced dl_iterate_phdr function// and dl_* function which uses malloc functionsif (info != NULL) {storeAllocationStack(info->allocStack);}if (p == NULL) {InternalMonitoringDisablerThreadUp();// WARNINGInternalMonitoringDisablerThreadDown();} }

并通過leaktracer::MemoryTrace::GetInstance().registerRelease(ptr, false)銷毀一個內存分配記錄：

// removes allocation's info from the map inline void MemoryTrace::registerRelease(void *p, bool is_array) {if (!AllMonitoringIsDisabled() && __monitoringReleases && p != NULL) {MutexLock lock(__allocations_mutex);allocation_info_t *info = __allocations.find(p);if (info != NULL) {if (info->isArray != is_array) {InternalMonitoringDisablerThreadUp();// WARNINGInternalMonitoringDisablerThreadDown();}__allocations.release(p);}} }

整體來看LeakTracer的設計與實現都并不復雜，因而能夠trace的memory issue也就有限。比如，LeakTracer就無法trace多次釋放等問題。但它也足以作為我們編寫更強大的memory issue trace工具的基礎了。

Done。

參考文檔：
Android下打印調試堆棧方法
dladdr - 獲取某個地址的符號信息
LeakTracer for Android
http://androidxref.com/5.0.0_r2/xref/hardware/ti/omap4-aah/stacktrace.c
http://www.newsmth.net/nForum/#!article/KernelTech/413

總結

以上是生活随笔為你收集整理的使用LeakTracer检测android NDK C/C++代码中的memory leak的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： OkHttp3中的HTTP/2首部压缩
下一篇：在C代码调用C++代码