代碼基於Android2.3.x版本
Android為Java程序提供了方便的內存泄露信息和工具（如MAT），便於查找。但是，對於純粹C/C++ 編寫的natvie進程，卻不那么容易查找內存泄露。傳統的C/C＋＋程序可以使用valgrind工具，也可以使用某些代碼檢查工具。幸運的是，Google的bionic庫為我們查找內存泄露提供了一個非常棒的API－－get_malloc_leak_info。利用它，我們很容易通過得到backtrace的方式找到涉嫌內存泄露的地方。
代碼原理分析
我們可以使用adb shell setprop libc.debug.malloc 1來設置內存的調試等級（debug_level），更詳細的等級解釋見文件bionic/libc/bionic/malloc_debug_common.c中的注釋：
/* Handle to shared library where actual memory allocation is implemented. * This library is loaded and memory allocation calls are redirected there * when libc.debug.malloc environment variable contains value other than * zero: * 1 – For memory leak detections. * 5 – For filling allocated / freed memory with patterns defined by * CHK_SENTINEL_VALUE, and CHK_FILL_FREE macros. * 10 – For adding pre-, and post- allocation stubs in order to detect * buffer overruns. * Note that emulator’s memory allocation instrumentation is not controlled by * libc.debug.malloc value, but rather by emulator, started with -memcheck * option. Note also, that if emulator has started with -memcheck option, * emulator’s instrumented memory allocation will take over value saved in * libc.debug.malloc. In other words, if emulator has started with -memcheck * option, libc.debug.malloc value is ignored. * Actual functionality for debug levels 1-10 is implemented in * libc_malloc_debug_leak.so, while functionality for emultor’s instrumented * allocations is implemented in libc_malloc_debug_qemu.so and can be run inside * the emulator only. */
對於不同的調試等級，內存分配管理函數操作句柄將指向不同的內存分配管理函數。這樣，內存的分配和釋放，在不同的的調試等級下，將使用不同的函數版本。 詳細過程如下：
如下面代碼注釋所說，在__libc_init例程中會調用malloc_debug_init進行初始化，進而調用malloc_init_impl（在一個進程中，使用pthread_once保證其只被執行一次）
在malloc_init_impl中，會打開對應的C庫，解析出函數符號：malloc_debug_initialize（見行366），並執行之（行373）
當debug_level被設置為1、5、10時，打開庫”/system/lib/libc_malloc_debug_leak.so”。在文件bionic/libc/bionic/malloc_debug_leak.c中，實現了malloc_debug_initialize，但只為返回0的空函數。若為20，則打開的是：”/system/lib/libc_malloc_debug_qemu.so”
接着，針對不同的debug_level，解析出不同的內存操作函數malloc/free/calloc/realloc/memalign實現：
對於debug_level等級1、5、10的情況，malloc/free/calloc/realloc/memalign各種版本的實現位於文件bionic/libc/bionic/malloc_debug_leak.c中。如debug_level為5時的情況，malloc/free/則是在分配內存時將分配的內存填充為0xeb，釋放時填充為0xef：
當debug_level為1調試memory leak時，其實現是打出backtrace：
void* leak_malloc(size_t bytes) { // allocate enough space infront of the allocation to store the pointer for // the alloc structure. This will making free’ing the structer really fast!
// 1. allocate enough memory and include our header // 2. set the base pointer to be right after our header
void* base = dlmalloc(bytes + sizeof(AllocationEntry)); if (base != NULL) { pthread_mutex_lock(&gAllocationsMutex);
intptr_t backtrace[BACKTRACE_SIZE]; size_t numEntries = get_backtrace(backtrace, BACKTRACE_SIZE);
AllocationEntry* header = (AllocationEntry*)base; header->entry = record_backtrace(backtrace, numEntries, bytes); header->guard = GUARD;
// now increment base to point to after our header. // this should just work since our header is 8 bytes. base = (AllocationEntry*)base + 1;
pthread_mutex_unlock(&gAllocationsMutex); }
return base; }
該malloc函數在實際分配的bytes字節前額外分配了一塊數據用作AllocationEntry。在分配內存成功后，分配了一個擁有32個元素的指針數組，用於存放調用堆棧指針，調用函數get_backtrace將調用堆棧保存起來，也就是將各函數指針保存到數組backtrace中；然后使用record_backtrace記錄下該調用堆棧，然后讓AllocationEntry的entry成員指向它。函數record_backtrace會通過hash值在全局調用堆棧表gHashTable里查找。若沒找到，則創建一項調用堆棧信息，將其加入到全局表中。最后，將base所指向的地方往后移一下，然后它，就是分配的內存地址。 可見，該版本的malloc函數額外記錄了調用堆棧的信息。通過在分配的內存塊前加一個頭的方式，保存了如何查詢hash表調用堆棧信息的entry。
再來看一下record_backtrace函數，在分析其代碼之前，看一下結構體（文件malloc_debug_common.h）： struct HashEntry { size_t slot;// HashTable中的slots數組索引 HashEntry* prev;//前一項 HashEntry* next;//后一項，新添加時添加到后面 size_t numEntries;//調用堆棧中的函數指針數量 // fields above “size” are NOT sent to the host size_t size;//表示該次malloc操作所分配的內存數 size_t allocations;//調用的次數，即此處的malloc被調用了多少次 intptr_t backtrace[0];//調用堆棧 };
typedef struct HashTable HashTable; struct HashTable { size_t count; HashEntry* slots[HASHTABLE_SIZE];//HASHTABLE_SIZE=1543 }; 和在一個進程中，有一個全局的變量gHashTable，用於記錄誰最終調用了malloc分配內存的調用堆棧列表。gHashTable的類型是HashTable，其有一個指針，這個指針指向一個slots數組，該數組的最大容量是1543；數組中有多少有效的值由另一個成員count記錄。可以通過backtrace和 numEntries得到hash值，再與HASHTABLE_SIZE整除得到HashEntry在該數組中的索引，這樣就可以根據自身信息根據hash，快速得到在數組中的索引。 另一個結構體是HashEntry，因其成員存在指向前后的指針，所以它也是個鏈表，hash值相同將添加到鏈表的后面。HashEntry第一個成員slot就是自身在數組中的索引，亦即由hash運算而來；最后一項即調用堆棧backtrace[0]，里面是函數指針，這個數組具體有多少項則由另一個成員numEntries記錄；size表示該次分配的內存的大小；allocations是分配次數，即有多少次同一調用路徑。 這兩個數據結構關系可由下圖表示：
在leak_malloc中調用record_backtrace記錄堆棧信息時，先由backtrace和numEntries得到hash值，再整除運算后得到在gHashTable中的數組索引；接着檢查是否已經存在該項，即有沒有分配了相同內存大小、同一調用路徑、記錄了相當數量的函數指針的HashEntry。若有，則直接在原有項上的allocations加1，沒有則創建新項：為HashEntry結構體分配內存（見行151，注意最后一個成員backtrace需要根據numEntries值來確定其有多少項），然后調用堆棧信息復制給HashEntry最后的一個成員backtrace。最后，還要為整個表格增加計數。 這樣record_backtrace函數完成了向全局表中添加backtrace信息的任務：要么新增加一項HashEntry，要么增加索引。
static HashEntry* record_backtrace(intptr_t* backtrace, size_t numEntries, size_t size) { size_t hash = get_hash(backtrace, numEntries);//得到backtrace和numEntries的hash值 size_t slot = hash % HASHTABLE_SIZE;//整除,得到的是HashTable中的HashEntry數組索引
if (size & SIZE_FLAG_MASK) { debug_log(“malloc_debug: allocation %zx exceeds bit widthn”, size); abort(); }
if (gMallocLeakZygoteChild) size |= SIZE_FLAG_ZYGOTE_CHILD;
HashEntry* entry = find_entry(&gHashTable, slot, backtrace, numEntries, size); //上面一行: 在全局表中搜索該項是否已經存在，即是否該調用路徑是否已經被調用過 if (entry != NULL) { entry->allocations++;//若調用過，則增加計數 } else {//若沒有調用，則創建一新項 // create a new entry entry = (HashEntry*)dlmalloc(sizeof(HashEntry) + numEntries*sizeof(intptr_t));//為該項分配內存， if (!entry)//接上一行:因HashEntry最后一項是intptr_t backtrace[0];故它是一動態長度，所有numEntries*sizeof(intptr_t) return NULL; entry->allocations = 1; entry->slot = slot; entry->prev = NULL; entry->next = gHashTable.slots[slot]; entry->numEntries = numEntries; entry->size = size;
memcpy(entry->backtrace, backtrace, numEntries * sizeof(intptr_t));//將backtrace拷貝到entry結構體的后面的內存中
gHashTable.slots[slot] = entry;//將新分配的並經過賦值的一項HashEntry添加到HashTable中的數組中去
if (entry->next != NULL) { entry->next->prev = entry; }
// we just added an entry, increase the size of the hashtable gHashTable.count++;//增加計數 }
return entry; }
在leak_free函數中會釋放上述全局hash表中的堆棧項（見行550）：
void leak_free(void* mem) { if (mem != NULL) { pthread_mutex_lock(&gAllocationsMutex);
// check the guard to make sure it is valid AllocationEntry* header = (AllocationEntry*)mem – 1;
if (header->guard != GUARD) { // could be a memaligned block if (((void**)mem)[-1] == MEMALIGN_GUARD) { mem = ((void**)mem)[-2]; header = (AllocationEntry*)mem – 1; } }
if (header->guard == GUARD || is_valid_entry(header->entry)) { // decrement the allocations HashEntry* entry = header->entry; entry->allocations–; if (entry->allocations <= 0) { remove_entry(entry); dlfree(entry); }
// now free the memory! dlfree(header); } else { debug_log(“WARNING bad header guard: ’0x%x’! and invalid entry: %pn”, header->guard, header->entry); }
pthread_mutex_unlock(&gAllocationsMutex); } }
因此，在全局表中剩下的未被釋放的項，就是分配了內存但未被釋放的調用了malloc的調用堆棧。
get_malloc_leak_info
函數get_malloc_leak_info用於獲取內存泄露信息。在分配內存時，記錄下調用堆棧，在釋放時清除它們。這樣，剩下的就很有可能是產生內存泄露的根源。那么如何獲取該內存調用堆棧全局hash表呢？在文件malloc_debug_common.c中提供了函數get_malloc_leak_info，可以獲取該堆棧信息。 函數get_malloc_leak_info接收5個參數，用於各種存放各種變量的地址，調用結束后，這些變量將得到修改。如其代碼注釋所說： *info將指向在該函數中分配的整塊內存，這些內存空間大小為overallSize； 整個空間若干小項組成，每項的大小為infoSize，這個小項的數據結構等同於HashEntry中自size成員開始的結構，即第一個成員是malloc分配的內存大小，第二個成員是allocations，即多次有着相同調用堆棧的計數，最后一項是backtrace，共32（BACKTRACE_SIZE）個指針值的空間。因此，*info指向的大內存塊包含了共有overallSize/infoSize個小項。注意HashEntry中backtrace數組是按實際數量分配的，而此處則統一按32個分配空間，若不到32個，則后面的值置0； totalMemory是malloc分配的所有內存的大小； 最后一個參數是backtraceSize，即32（BACKTRACE_SIZE）
函數get_malloc_leak_info首先檢查傳遞進來的變量是否合法，以及全局堆棧中是否有堆棧項： void get_malloc_leak_info(uint8_t** info, size_t* overallSize, size_t* infoSize, size_t* totalMemory, size_t* backtraceSize) { // don’t do anything if we have invalid arguments if (info == NULL || overallSize == NULL || infoSize == NULL || totalMemory == NULL || backtraceSize == NULL) { return; } *totalMemory = 0;
pthread_mutex_lock(&gAllocationsMutex);
if (gHashTable.count == 0) { *info = NULL; *overallSize = 0; *infoSize = 0; *backtraceSize = 0; goto done; }
接着查看全局堆棧表中有多少項，然后分配一塊內存，用於保存指針，這些指針用於指向gHashTable中的所有HashEntry項，並順便計數出已分配但未釋放的內存總數量totalMemory用於返回給調用者。最后一個參數是調用堆棧中的函數指針個數，實際值為BACKTRACE_SIZE，即32。. void** list = (void**)dlmalloc(sizeof(void*) * gHashTable.count);
// get the entries into an array to be sorted int index = 0; int i; for (i = 0 ; i < HASHTABLE_SIZE ; i++) {//遍歷gHashTable全部項 HashEntry* entry = gHashTable.slots[i]; while (entry != NULL) {//有效項放到list中去 list[index] = entry; *totalMemory = *totalMemory +//計算總分配的內存 ((entry->size & ~SIZE_FLAG_MASK) * entry->allocations); index++; entry = entry->next;//讓entry指向下一個，即相同的slot值 } }//經過此for循環，將全局表中所有的堆棧項指針存放到list指向的表中
// XXX: the protocol doesn’t allow variable size for the stack trace (yet) *infoSize = (sizeof(size_t) * 2) + (sizeof(intptr_t) * BACKTRACE_SIZE);//32個指針值項， //注意: info前面是兩個size_t變量，它們是HashEntry中的size和allocations兩個成員,后面是backtrace *overallSize = *infoSize * gHashTable.count;//計算所有調用堆棧項所需內存 *backtraceSize = BACKTRACE_SIZE;
最后，為所有調用堆棧項信息分配內存，即info指向的地方；並將gHashTable中的調用堆棧信息（即list表中的HashEntry自其結構體成員size后面的值）拷貝到info所指向的內存中。
// now get A byte array big enough for this *info = (uint8_t*)dlmalloc(*overallSize);//為所有堆棧項分配內存，包括各項的2個size_t變量
if (*info == NULL) {//分配不成功，沒內存了 *overallSize = 0; goto out_nomem_info; }
qsort((void*)list, gHashTable.count, sizeof(void*), hash_entry_compare);//為列表中的項排序
uint8_t* head = *info; const int count = gHashTable.count; for (i = 0 ; i < count ; i++) { HashEntry* entry = list[i]; size_t entrySize = (sizeof(size_t) * 2) + (sizeof(intptr_t) * entry->numEntries); if (entrySize < *infoSize) { /* we’re writing less than a full entry, clear out the rest */ memset(head + entrySize, 0, *infoSize – entrySize);//調用堆棧32項中未填滿的部分 } else { /* make sure the amount we’re copying doesn’t exceed the limit */ entrySize = *infoSize; }//下面的一行將32個指針占用空間加上前面兩個size_t變量的值復制到info項中 memcpy(head, &(entry->size), entrySize);//size_t變量分別為size和allocations head += *infoSize;//讓head指向下一個info所在內存 }
out_nomem_info: dlfree(list);
done: pthread_mutex_unlock(&gAllocationsMutex); }
當程序運行結束時，一般來說，內存都應該釋放，這時我們可以調用get_malloc_leak_info獲取未被釋放的調用堆棧項。原理上，這些就是內存泄露的地方。但實際情況可能是，在我們運行get_malloc_leak_info時，某些內存應該保留還不應該釋放。 另外，我們有時要檢查的進程是守護進程，不會退出。所以有些內存應該一直保持下去，不被釋放。這時，我們可以選擇某個狀態的一個時刻來查看未釋放的內存，比如在剛進入時的idle狀態時的一個時刻，使用get_malloc_leak_info獲取未釋放的內存信息，然后在程序執行某些操作結束后返回Idle狀態時，再次使用get_malloc_leak_info獲取未釋放的內存信息。兩種信息對比，新多出來的調用堆棧項，就存在涉嫌內存泄露。 使用get_malloc_leak_info函數的樣例代碼如下：
typedef struct { size_t size;//分配的內存 size_t dups;//重復數 intptr_t * backtrace;//調用堆棧指針 } AllocEntry;
uint8_t *info = NULL; size_t overallSize = 0; size_t infoSize = 0; size_t totalMemory = 0; size_t backtraceSize = 0;
get_malloc_leak_info(&info, &overallSize, &infoSize, &totalMemory, &backtraceSize); LOGI(“returned from get_malloc_leak_info, info=0x%x, overallSize=%d, infoSize=%d, totalMemory=%d, backtraceSize=%d”, (int)info, overallSize, infoSize, totalMemory, backtraceSize); if (info) { uint8_t *ptr = info; size_t count = overallSize / infoSize;
snprintf(buffer, SIZE, ” Allocation count %in”, count); result.append(buffer); snprintf(buffer, SIZE, ” Total meory %in”, totalMemory); result.append(buffer);
AllocEntry * entries = new AllocEntry[count];//數組
for (size_t i = 0; i < count; i++) {讓獲取的堆棧信息填充到 AllocEntry數組中 // Each entry should be size_t, size_t, intptr_t[backtraceSize] AllocEntry *e = &entries[i];
e->size = *reinterpret_cast<size_t *>(ptr); ptr += sizeof(size_t);
e->dups = *reinterpret_cast<size_t *>(ptr); ptr += sizeof(size_t);
e->backtrace = reinterpret_cast<intptr_t *>(ptr); ptr += sizeof(intptr_t) * backtraceSize; }
具體調試步驟： 參考http://freepine.blogspot.com/2010/02/analyze-memory-leak-of-android-native.html 下載其補丁包和python工具包 將代碼補丁達到android源碼中的frameworks/base下，重新編譯生成image，燒進手機板里，這時會在/system/bin/下有個二進制程序memorydumper。該代碼補丁包向mediaserver進程中添加一個服務，二進制程序通過Binder IPC使用該服務。該服務使用get_malloc_leak_info獲取未釋放內存信息。
step1．設置調試等級並重啟mediaserver進程 adb shell setprop libc.debug.malloc 1 adb shell ps mediaserver adb shell kill <mediaserver_pid>
它的目的是讓mediaserver進程使用leak_malloc的版本。當設置調試等級后，殺死mediaserver進程，android系統將自動重啟它。這時，它重新加載libc庫，內存分配函數通過handle將使用leak_malloc、leak_free版本。 Step2:在某初始狀態下，如在使用“照相機”程序之前，執行memorydumper，記錄下此時未釋放的內存： $ adb shell /system/bin/memorydumper $ adb pull /data/memstatus_<mediaserver_pid>.0 .
Step3：執行某些操作，如拍照、錄制視頻或播放幾首歌曲，然后退出這些應用程序；
Step4：再次執行memorydumper，記錄下此時未釋放的內存；通過比較工具，比較此次和step2中的差異；這些差異就是有內存泄露嫌疑的地方。因為第一得到的未釋放的可能就是那個時刻不該釋放的，比較就是將它們排除掉。 $ adb pull /data/memstatus_<mediaserver_pid>.1 . $ diff memstatus_<mediaserver_pid>.0 memstatus_<mediaserver_pid>.1 >diff_0_1
Step5：獲取maps文件。根據該文件，可以得到.so庫文件所在地址范圍空間，用於將調用堆棧函數符號地址解析出來。 $ adb pull /proc/<mediaserver_pid>/maps your_path
Step5.執行參考鏈接中的python腳本： ./addr2func.py –root-dir=~/u8500-android-2.3_v4.30 –maps-file=maps –product=u8500 diff._0_1>memleak.backtrace 該腳本將通過分析maps文件得到地址段對應的庫文件所占用的地址空間，得到每個調用堆棧的地址對應的庫，通過下面的命令，得到對應的經過編譯器mangled后的函數名稱、源文件及其行號： [root-dir]/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-addr2line -f -e [root-dir]/ /out/target/product/[product]/symbols/[libname] callstack_address
然后使用[root-dir]/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-c++filt進行函數的demangle，得到與源碼一致的函數名稱，使我們更易辨認。
一個例子的snapshot： 下面的截圖是第一次使用memorydumper得到的調用堆棧地址：
下面的截圖是第二次使用memorydumper得到的調用堆棧地址：
兩者進行diff比較后得到的差異：
使用addr2func后得到的調用堆棧：
本文鏈接地址: http://www.redwolf-blog.com/?p=1233
原創文章，版權©紅狼博客所有, 轉載隨意，但請注明出處。