當(dāng)前位置：首頁 > 编程语言 > c/c++ >内容正文

c/c++

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

發(fā)布時間：2024/4/11 c/c++ 32 豆豆

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

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

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

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

LeakTracer的下載、編譯

LeakTracer official site。LeakTracer github repo?？梢酝ㄟ^git clone將LeakTracer的code download下來，這個項(xiàng)目的結(jié)構(gòu)如下：

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

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

將自己的程序與libleaktracer.a進(jìn)行鏈接，也就是將自己的程序一個靜態(tài)鏈接庫libleaktracer.a進(jìn)行鏈接，我們知道靜態(tài)鏈接是會將庫的代碼揉進(jìn)我們自己項(xiàng)目的目標(biāo)代碼so中的。

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

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

這里我們就將libleaktracer的代碼復(fù)制進(jìn)我們的項(xiàng)目中，放在jni/3rd/目錄下。然后修改我們的jni的Android.mk，主要改動內(nèi)容為在適當(dāng)?shù)奈恢迷黾尤缦聝?nèi)容：

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

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

APP_OPTIM := debug

這樣才能在編譯的時候，帶進(jìn)更多的debug信息進(jìn)目標(biāo)文件。

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

LeakTracer的集成

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

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

然后在結(jié)束時的銷毀函數(shù)中加入如下的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。

集成結(jié)束，開始運(yùn)行來檢測memory leak。我們的app剛一運(yùn)行起來，就發(fā)生了一個SIGSEGV的crash：

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

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

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，再次運(yùn)行我們的程序，這次能夠看到這樣的一些信息：

可以看到，這個crash發(fā)生在libleaktracer的malloc函數(shù)中，調(diào)用棧為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; }

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

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

p = LT_MALLOC(size);

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

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

函數(shù)指針則定義在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);

函數(shù)指針則定義在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);

這些個函數(shù)指針都通過結(jié)構(gòu)體數(shù)組static libc_alloc_func_t libc_alloc_funcs，在MemoryTrace::init_no_alloc_allowed()中進(jìn)行初始化( 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()中進(jìn)行初始化的這段代碼，主要是找到系統(tǒng)本來的那組分配/釋放內(nèi)存的函數(shù)的地址，并保存在lt_malloc這一組函數(shù)指針中。

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

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

看到這里，也就不難理解為何需要先加載libleaktracer了?？偨Y(jié)一下，有兩個原因，一是在動態(tài)鏈接時，程序?qū)τ诜峙?釋放內(nèi)存的函數(shù)的調(diào)用能鏈接到libleaktracer的實(shí)現(xiàn)，二是這里能夠找到系統(tǒng)的那組分配/釋放內(nèi)存的函數(shù)。

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

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

但運(yùn)行起來之后，又出現(xiàn)了crash了。

這次倒是可以通過Eclipse的"Debug As"的"Android Native Application"抓到發(fā)生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; }

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

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

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()接收兩個參數(shù)，一個是_Unwind_Reason_Code () (_Unwind_Context , void *)類型的函數(shù)指針_Unwind_Trace_Fn，另外一個是userdata，會被作為每次調(diào)用 _Unwind_Trace_Fn的第二個參數(shù)傳入。 _Unwind_Backtrace()的執(zhí)行，會針對調(diào)用鏈中的每一級stack frame調(diào)用trace callback _Unwind_Trace_Fn，在這個callback的實(shí)現(xiàn)中，我們可以保存stack frame的信息。

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

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**()來獲得調(diào)用棧。系統(tǒng)還提供了_Unwind_GetIP**()用來幫助我們獲取每一個stack frame的指令指針I(yè)P。

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

# 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.

既然有了沒被正確釋放的內(nèi)存分配時候的backtrace，那就將它們轉(zhuǎn)換到代碼文件的行數(shù)吧。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/下面的。

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

貌似完全無法得到backtrace對應(yīng)的代碼行數(shù)呢。問題出在哪里了呢？

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

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

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

于是我們定義一個靜態(tài)的Dl_info結(jié)構(gòu)對象s_P2pSODlInfo，并在MemoryTrace::init_no_alloc_allowed()中，初始化lt_calloc等函數(shù)指針的那段code下面加一行對dladdr()的調(diào)用：

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);

這里我們就通過函數(shù)init_no_alloc_allowed的地址來獲得整個library內(nèi)存映射的基地址。同時修改_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 內(nèi)存映射的基地址。

再次運(yùn)行我們的程序，產(chǎn)生memory leak的trace文件并pull下來，并用leak-analyze-addr2line工具進(jìn)行分析，終于可以獲得leak的內(nèi)存分配時的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)

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

LeakTracer的設(shè)計(jì)與實(shí)現(xiàn)

這里我們再來分析一下LeakTracer的設(shè)計(jì)與實(shí)現(xiàn)。

LeakTracer主要的設(shè)計(jì)思路為：

實(shí)現(xiàn)一組內(nèi)存的分配/釋放函數(shù)，這組函數(shù)的函數(shù)原型與系統(tǒng)的那一組完全一樣，讓被trace的library對于內(nèi)存的分配/釋放函數(shù)的調(diào)用都鏈接到自己實(shí)現(xiàn)的這一組函數(shù)中以override掉系統(tǒng)的那組內(nèi)存/分配釋放函數(shù)；

自己實(shí)現(xiàn)的這組函數(shù)中的內(nèi)存分配函數(shù)記錄分配相關(guān)的信息，包括分配的內(nèi)存的大小，callstack等，并調(diào)用系統(tǒng)本來的內(nèi)存分配函數(shù)去分配內(nèi)存；

自己實(shí)現(xiàn)的這組函數(shù)中的內(nèi)存釋放函數(shù)則銷毀內(nèi)存分配的相關(guān)記錄，并使用系統(tǒng)的內(nèi)存釋放函數(shù)真正的釋放內(nèi)存；

在trace結(jié)束時，遍歷所有保存的內(nèi)存分配記錄的信息，并把這些信息保存進(jìn)文件以供進(jìn)一步的分析。

LeakTracer實(shí)現(xiàn)的用于override系統(tǒng)內(nèi)存分配/釋放函數(shù)的那組函數(shù)在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; }

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

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

// 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)銷毀一個內(nèi)存分配記錄：

// 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的設(shè)計(jì)與實(shí)現(xiàn)都并不復(fù)雜，因而能夠trace的memory issue也就有限。比如，LeakTracer就無法trace多次釋放等問題。但它也足以作為我們編寫更強(qiáng)大的memory issue trace工具的基礎(chǔ)了。

Done。

參考文檔：
Android下打印調(diào)試堆棧方法
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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

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