大胸美女被操网站,欧美无吗,少妇高潮hd,青娱乐草草,亚洲精品国产精华液,青青草视频免费,久草国产在线视频,黄色天堂网站

本文將分三個(gè)部分闡述如何實(shí)現(xiàn) Android Native 內(nèi)存泄漏監(jiān)控，包括代理實(shí)現(xiàn)的三種方案（Inline Hook、PLT/GOT Hook、LD_PRELOAD）及其優(yōu)缺點(diǎn)，以及如何檢測(cè)Native內(nèi)存泄露和獲取Android Native堆棧的方法。本文將提供一套比較全面的解決思路，幫助大家更好地檢測(cè) Android Native 內(nèi)存泄漏問題。

作者：yeconglu

一個(gè)完整的 Android Native 內(nèi)存泄漏檢測(cè)工具主要包含三部分：代理實(shí)現(xiàn)、堆?；厮莺途彺婀芾怼４韺?shí)現(xiàn)是解決 Android 平臺(tái)上接入問題的關(guān)鍵部分，堆?；厮輨t是性能和穩(wěn)定性的核心要素。

本文會(huì)從三個(gè)方面介紹如何實(shí)現(xiàn) Native 內(nèi)存泄漏監(jiān)控:

介紹代理實(shí)現(xiàn)的三個(gè)方案 Inline Hook、PLT/GOT Hook、LD_PRELOAD 的實(shí)現(xiàn)方式和優(yōu)缺點(diǎn)。
介紹檢測(cè) Android Native 內(nèi)存泄露的基本思路和包含緩存邏輯的示例代碼。
介紹獲取 Android Native 堆棧的方法，用于記錄分配內(nèi)存時(shí)的調(diào)用棧。

一、代理內(nèi)存管理函數(shù)實(shí)現(xiàn)

首先我們來介紹一下代理內(nèi)存管理函數(shù)實(shí)現(xiàn)的三個(gè)方案：

Inline Hook
PLT/GOT Hook
LD_PRELOAD

1.1 Native Hook

1.1.1 方案對(duì)比：Inline Hook和PLT/GOT Hook

目前主要有兩種Native Hook方案：Inline Hook和PLT/GOT Hook。

指令重定位是指在計(jì)算機(jī)程序的鏈接和裝載過程中，對(duì)程序中的相對(duì)地址進(jìn)行調(diào)整，使其指向正確的內(nèi)存位置。這是因?yàn)槌绦蛟诰幾g時(shí)，無法預(yù)知在運(yùn)行時(shí)會(huì)被裝載到內(nèi)存的哪個(gè)位置，所以編譯后的程序中，往往使用相對(duì)地址來表示內(nèi)存位置。然而在實(shí)際運(yùn)行時(shí)，程序可能被裝載到內(nèi)存的任何位置，因此需要在裝載過程中，根據(jù)程序?qū)嶋H被裝載到的內(nèi)存地址，對(duì)程序中的所有相對(duì)地址進(jìn)行調(diào)整，這個(gè)過程就叫做重定位。

在進(jìn)行Inline Hook時(shí)，如果直接修改目標(biāo)函數(shù)的機(jī)器碼，可能會(huì)改變?cè)械奶D(zhuǎn)指令的相對(duì)地址，從而使程序跳轉(zhuǎn)到錯(cuò)誤的位置，因此需要進(jìn)行指令重定位，確保修改后的指令能正確地跳轉(zhuǎn)到預(yù)期的位置。

1.1.2 案例：在Android應(yīng)用中Hook `malloc` 函數(shù)

為了更好地理解Native Hook的應(yīng)用場(chǎng)景，我們來看一個(gè)實(shí)際的案例：在Android應(yīng)用中Hook malloc 函數(shù)，以監(jiān)控文件的打開操作。

1.1.2.1 Inline Hook實(shí)現(xiàn)

#include <stdio.h>
#include <dlfcn.h>
#include <unistd.h>
#include <string.h>
#include <sys/mman.h>
#include <android/log.h>

#define TAG "NativeHook"
#define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, TAG, __VA_ARGS__)

typedef void* (*orig_malloc_func_type)(size_t size);

orig_malloc_func_type orig_malloc;

unsigned char backup[8];  // 用于保存原來的機(jī)器碼

void* my_malloc(size_t size) {
    LOGD("內(nèi)存分配: %zu 字節(jié)", size);

    // 創(chuàng)建一個(gè)新的函數(shù)指針orig_malloc_with_backup，指向一個(gè)新的內(nèi)存區(qū)域
    void *orig_malloc_with_backup = mmap(NULL, sizeof(backup) + 8, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
    
    // 將備份的指令A(yù)和B復(fù)制到新的內(nèi)存區(qū)域
    memcpy(orig_malloc_with_backup, backup, sizeof(backup));

    // 在新的內(nèi)存區(qū)域的末尾添加一個(gè)跳轉(zhuǎn)指令，使得執(zhí)行流跳轉(zhuǎn)回原始malloc函數(shù)的剩余部分
    unsigned char *jump = (unsigned char *)orig_malloc_with_backup + sizeof(backup);
    jump[0] = 0x01;  // 跳轉(zhuǎn)指令的機(jī)器碼
    *(void **)(jump + 1) = (unsigned char *)orig_malloc + sizeof(backup);  // 跳轉(zhuǎn)目標(biāo)的地址

    // 調(diào)用orig_malloc_with_backup函數(shù)指針
    orig_malloc_func_type orig_malloc_with_backup_func_ptr = (orig_malloc_func_type)orig_malloc_with_backup;
    void *result = orig_malloc_with_backup_func_ptr(size);

    // 釋放分配的內(nèi)存區(qū)域
    munmap(orig_malloc_with_backup, sizeof(backup) + 8);

    return result;
}

void *get_function_address(const char *func_name) {
    void *handle = dlopen("libc.so", RTLD_NOW);
    if (!handle) {
        LOGD("錯(cuò)誤: %s", dlerror());
        return NULL;
    }

    void *func_addr = dlsym(handle, func_name);
    dlclose(handle);

    return func_addr;
}

void inline_hook() {
    void *orig_func_addr = get_function_address("malloc");
    if (orig_func_addr == NULL) {
        LOGD("錯(cuò)誤: 無法找到 'malloc' 函數(shù)的地址");
        return;
    }

    // 備份原始函數(shù)
    orig_malloc = (orig_malloc_func_type)orig_func_addr;

    // 備份原始機(jī)器碼
    memcpy(backup, orig_func_addr, sizeof(backup));

    // 更改頁(yè)面保護(hù)
    size_t page_size = sysconf(_SC_PAGESIZE);
    uintptr_t page_start = (uintptr_t)orig_func_addr & (~(page_size - 1));
    mprotect((void *)page_start, page_size, PROT_READ | PROT_WRITE | PROT_EXEC);

    // 構(gòu)造跳轉(zhuǎn)指令
    unsigned char jump[8] = {0};
    jump[0] = 0x01;  // 跳轉(zhuǎn)指令的機(jī)器碼
    *(void **)(jump + 1) = my_malloc;  // 我們的鉤子函數(shù)的地址

    // 將跳轉(zhuǎn)指令寫入目標(biāo)函數(shù)的入口點(diǎn)
    memcpy(orig_func_addr, jump, sizeof(jump));
}

void unhook() {
    void *orig_func_addr = get_function_address("malloc");
    if (orig_func_addr == NULL) {
        LOGD("錯(cuò)誤: 無法找到 'malloc' 函數(shù)的地址");
        return;
    }

    // 更改頁(yè)面保護(hù)
    size_t page_size = sysconf(_SC_PAGESIZE);
    uintptr_t page_start = (uintptr_t)orig_func_addr & (~(page_size - 1));
    mprotect((void *)page_start, page_size, PROT_READ | PROT_WRITE | PROT_EXEC);

    // 將備份的機(jī)器碼寫入目標(biāo)函數(shù)的入口點(diǎn)
    memcpy(orig_func_addr, backup, sizeof(backup));
}

在my_malloc中，我們需要先執(zhí)行備份的指令，然后將執(zhí)行流跳轉(zhuǎn)回原始malloc函數(shù)的剩余部分：

在my_malloc函數(shù)中，創(chuàng)建一個(gè)新的函數(shù)指針orig_malloc_with_backup，它指向一個(gè)新的內(nèi)存區(qū)域，該區(qū)域包含備份的指令以及一個(gè)跳轉(zhuǎn)指令。
將備份的指令復(fù)制到新的內(nèi)存區(qū)域。
在新的內(nèi)存區(qū)域的末尾添加一個(gè)跳轉(zhuǎn)指令，使得執(zhí)行流跳轉(zhuǎn)回原始malloc函數(shù)的剩余部分。
在my_malloc中，調(diào)用orig_malloc_with_backup函數(shù)指針。

這里有三個(gè)難點(diǎn)，下面詳細(xì)解釋一下。

####### 1.1.2.1.1 如何修改內(nèi)存頁(yè)的保護(hù)屬性

orig_func_addr & (~(page_size - 1)) 這段代碼的作用是獲取包含 orig_func_addr 地址的內(nèi)存頁(yè)的起始地址。這里使用了一個(gè)技巧：page_size 總是2的冪，因此 page_size - 1 的二進(jìn)制表示形式是低位全為1，高位全為0，取反后低位全為0，高位全為1。將 orig_func_addr 與 ~(page_size - 1) 進(jìn)行與操作，可以將 orig_func_addr 的低位清零，從而得到內(nèi)存頁(yè)的起始地址。

mprotect((void *)page_start, page_size, PROT_READ | PROT_WRITE | PROT_EXEC); 這行代碼的作用是修改內(nèi)存頁(yè)的保護(hù)屬性。mprotect 函數(shù)可以設(shè)置一塊內(nèi)存區(qū)域的保護(hù)屬性，它接受三個(gè)參數(shù)：需要修改的內(nèi)存區(qū)域的起始地址，內(nèi)存區(qū)域的大小，以及新的保護(hù)屬性。在這里，我們將包含 orig_func_addr 地址的內(nèi)存頁(yè)的保護(hù)屬性設(shè)置為可讀、可寫、可執(zhí)行（PROT_READ | PROT_WRITE | PROT_EXEC），以便我們可以修改這個(gè)內(nèi)存頁(yè)中的代碼。

####### 1.1.2.1.2 如何恢復(fù)原函數(shù)

想要恢復(fù)原來的函數(shù)，我們需要在Hook之前保存原來的機(jī)器碼，然后在需要恢復(fù)時(shí)，將保存的機(jī)器碼寫回函數(shù)的入口點(diǎn)。

代碼中的backup數(shù)組用于保存原始機(jī)器碼。在inline_hook函數(shù)中，我們?cè)谛薷臋C(jī)器碼之前先將原始機(jī)器碼復(fù)制到backup數(shù)組。然后，我們提供了一個(gè)unhook函數(shù)，用于恢復(fù)原始機(jī)器碼。在需要恢復(fù)malloc函數(shù)時(shí)，可以調(diào)用unhook函數(shù)。

需要注意的是，這個(gè)示例假設(shè)函數(shù)的入口點(diǎn)的機(jī)器碼長(zhǎng)度是8字節(jié)。在實(shí)際使用時(shí)，你需要根據(jù)實(shí)際情況確定機(jī)器碼的長(zhǎng)度，并相應(yīng)地調(diào)整backup數(shù)組的大小和memcpy函數(shù)的參數(shù)。

####### 1.1.2.1.3 如何實(shí)現(xiàn)指令重定位

我們以一個(gè)簡(jiǎn)單的ARM64匯編代碼為例，演示如何進(jìn)行指令重定位。假設(shè)我們有以下目標(biāo)函數(shù)：

TargetFunction:
    mov x29, sp
    sub sp, sp, #0x10
    ; ... 其他指令 ...
    bl SomeFunction
    ; ... 其他指令 ...
    b TargetFunctionEnd

我們要在TargetFunction的開頭插入一個(gè)跳轉(zhuǎn)指令，將執(zhí)行流跳轉(zhuǎn)到我們的HookFunction。為了實(shí)現(xiàn)這一目標(biāo)，我們需要進(jìn)行以下操作：

備份被覆蓋的指令：我們需要備份TargetFunction開頭的指令，因?yàn)樗鼈儗⒈晃覀兊奶D(zhuǎn)指令覆蓋。在這個(gè)例子中，我們需要備份mov x29, sp和sub sp, sp, #0x10兩條指令。
插入跳轉(zhuǎn)指令：在TargetFunction的開頭插入一個(gè)跳轉(zhuǎn)到HookFunction的跳轉(zhuǎn)指令。在ARM64匯編中，我們可以使用b指令實(shí)現(xiàn)這一目標(biāo)：
```
b HookFunction
```
處理被覆蓋的指令：在HookFunction中，我們需要執(zhí)行被覆蓋的指令。在這個(gè)例子中，我們需要在HookFunction中執(zhí)行mov x29, sp和sub sp, sp, #0x10兩條指令。
重定位跳轉(zhuǎn)和數(shù)據(jù)引用：在HookFunction中，我們需要處理目標(biāo)函數(shù)中的跳轉(zhuǎn)和數(shù)據(jù)引用。在這個(gè)例子中，我們需要重定位bl SomeFunction和b TargetFunctionEnd兩條跳轉(zhuǎn)指令。根據(jù)目標(biāo)函數(shù)在內(nèi)存中的新地址，我們需要計(jì)算新的跳轉(zhuǎn)地址，并修改這兩條指令的操作數(shù)。
返回到目標(biāo)函數(shù)：在HookFunction中執(zhí)行完被覆蓋的指令和其他自定義操作后，我們需要返回到目標(biāo)函數(shù)的未被修改部分。在這個(gè)例子中，我們需要在HookFunction的末尾添加一個(gè)跳轉(zhuǎn)指令，將執(zhí)行流跳轉(zhuǎn)回TargetFunction的sub sp, sp, #0x10指令。

經(jīng)過以上步驟，我們成功地在TargetFunction中插入了一個(gè)跳轉(zhuǎn)到HookFunction的跳轉(zhuǎn)指令，并對(duì)目標(biāo)函數(shù)中的跳轉(zhuǎn)和數(shù)據(jù)引用進(jìn)行了重定位。這樣，當(dāng)執(zhí)行到TargetFunction時(shí)，程序?qū)⑻D(zhuǎn)到HookFunction執(zhí)行，并在執(zhí)行完被覆蓋的指令和其他自定義操作后，返回到目標(biāo)函數(shù)的未被修改部分。

1.1.2.2 PLT/GOT Hook實(shí)現(xiàn)

PLT（Procedure Linkage Table）和GOT（Global Offset Table）是Linux下動(dòng)態(tài)鏈接庫(kù)（shared libraries）中用于解析動(dòng)態(tài)符號(hào)的兩個(gè)重要表。

PLT（Procedure Linkage Table）：過程鏈接表，用于存儲(chǔ)動(dòng)態(tài)鏈接庫(kù)中函數(shù)的入口地址。當(dāng)程序調(diào)用一個(gè)動(dòng)態(tài)鏈接庫(kù)中的函數(shù)時(shí)，首先會(huì)跳轉(zhuǎn)到PLT中的對(duì)應(yīng)條目，然后再通過GOT找到實(shí)際的函數(shù)地址并執(zhí)行。

GOT（Global Offset Table）：全局偏移表，用于存儲(chǔ)動(dòng)態(tài)鏈接庫(kù)中函數(shù)和變量的實(shí)際地址。在程序運(yùn)行時(shí)，動(dòng)態(tài)鏈接器（dynamic linker）會(huì)根據(jù)需要將函數(shù)和變量的實(shí)際地址填充到GOT中。PLT中的條目會(huì)通過GOT來找到函數(shù)和變量的實(shí)際地址。

在PLT/GOT Hook中，我們可以修改GOT中的函數(shù)地址，使得程序在調(diào)用某個(gè)函數(shù)時(shí)實(shí)際上調(diào)用我們自定義的函數(shù)。這樣，我們可以在自定義的函數(shù)中添加額外的邏輯（如檢測(cè)內(nèi)存泄漏），然后再調(diào)用原始的函數(shù)。這種方法可以實(shí)現(xiàn)對(duì)程序的無侵入式修改，而不需要重新編譯程序。

#include <stdio.h>
#include <dlfcn.h>
#include <unistd.h>
#include <android/log.h>

#define TAG "NativeHook"
#define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, TAG, __VA_ARGS__)

typedef void* (*orig_malloc_func_type)(size_t size);

orig_malloc_func_type orig_malloc;

void* my_malloc(size_t size) {
    LOGD("Memory allocated: %zu bytes", size);
    return orig_malloc(size);
}

void plt_got_hook() {
    void **got_func_addr = (void **)dlsym(RTLD_DEFAULT, "malloc");
    if (got_func_addr == NULL) {
        LOGD("Error: Cannot find the GOT entry of 'malloc' function");
        return;
    }

    // Backup the original function
    orig_malloc = (orig_malloc_func_type)*got_func_addr;

    // Replace the GOT entry with the address of our hook function
    *got_func_addr = my_malloc;
}

上面代碼中的RTLD_DEFAULT是一個(gè)特殊的句柄值，表示在當(dāng)前進(jìn)程已加載的所有動(dòng)態(tài)鏈接庫(kù)中查找符號(hào)。當(dāng)使用RTLD_DEFAULT作為dlsym()的handle參數(shù)時(shí)，dlsym()會(huì)在當(dāng)前進(jìn)程已加載的所有動(dòng)態(tài)鏈接庫(kù)中查找指定的符號(hào)，而不僅僅是某個(gè)特定的動(dòng)態(tài)鏈接庫(kù)。

1.1.2.3 再看 Inline Hook 和 Got Hook 的區(qū)別

關(guān)鍵在于，兩種 Native Hook 方式的實(shí)現(xiàn)中，dlsym返回的地址含義是不一樣的：

Inline Hook

void *get_function_address(const char *func_name) {
    void *handle = dlopen("libc.so", RTLD_NOW);
    ...
    void *func_addr = dlsym(handle, func_name);
    dlclose(handle);

    return func_addr;
}

void *orig_func_addr = get_function_address("malloc");
memcpy(orig_func_addr, jump, sizeof(jump));

dlsym 返回的地址是函數(shù)在內(nèi)存中的實(shí)際地址，這個(gè)地址通常指向函數(shù)的入口點(diǎn)（即函數(shù)的第一條指令）。

Got Hook

void **got_func_addr = (void **)dlsym(RTLD_DEFAULT, "malloc");
*got_func_addr = my_malloc;

dlsym 返回的是 malloc 函數(shù)在 GOT 中的地址，注意void **got_func_addr是雙重指針。

1.2 使用`LD_PRELOAD`

使用LD_PRELOAD的方式，可以在不修改源代碼的情況下重載內(nèi)存管理函數(shù)。雖然這種方式在Android平臺(tái)上有很多限制，但是我們也可以了解下相關(guān)的原理。

LD_PRELOAD 是一個(gè)環(huán)境變量，用于在程序運(yùn)行時(shí)預(yù)加載動(dòng)態(tài)鏈接庫(kù)。通過設(shè)置 LD_PRELOAD，我們可以在程序運(yùn)行時(shí)強(qiáng)制加載指定的庫(kù)，從而在不修改源代碼的情況下改變程序的行為。這種方法通常用于調(diào)試、性能分析和內(nèi)存泄漏檢測(cè)等場(chǎng)景。

使用 LD_PRELOAD 檢測(cè)內(nèi)存泄漏的原理和方法如下：

原理：當(dāng)設(shè)置了 LD_PRELOAD 環(huán)境變量時(shí)，程序會(huì)在加載其他庫(kù)之前加載指定的庫(kù)。這使得我們可以在自定義庫(kù)中重載（override）一些原始庫(kù)（如 glibc）中的函數(shù)。在內(nèi)存泄漏檢測(cè)的場(chǎng)景中，我們可以重載內(nèi)存分配和釋放函數(shù)（如 malloc、calloc、realloc 和 free），以便在分配和釋放內(nèi)存時(shí)記錄相關(guān)信息。
方法：

a. 創(chuàng)建自定義庫(kù)：首先，我們需要?jiǎng)?chuàng)建一個(gè)自定義內(nèi)存泄露檢測(cè)庫(kù)，并在其中重載內(nèi)存分配和釋放函數(shù)。在這些重載的函數(shù)中，我們可以調(diào)用原始的內(nèi)存管理函數(shù)，并在分配內(nèi)存時(shí)將內(nèi)存塊及其相關(guān)信息（如分配大小、調(diào)用棧等）添加到全局內(nèi)存分配表中，在釋放內(nèi)存時(shí)從全局內(nèi)存分配表中刪除相應(yīng)的內(nèi)存塊。

b. 設(shè)置 LD_PRELOAD 環(huán)境變量：在運(yùn)行程序之前，我們需要設(shè)置 LD_PRELOAD 環(huán)境變量，使其指向自定義庫(kù)的路徑。這樣，程序在運(yùn)行時(shí)會(huì)優(yōu)先加載自定義庫(kù)，從而使用重載的內(nèi)存管理函數(shù)。

c. 運(yùn)行程序：運(yùn)行程序時(shí)，它將使用重載的內(nèi)存管理函數(shù)，從而記錄內(nèi)存分配和釋放的信息。我們可以在程序運(yùn)行過程中或運(yùn)行結(jié)束后，檢查全局內(nèi)存分配表中仍然存在的內(nèi)存塊，從而檢測(cè)內(nèi)存泄漏。

通過使用 LD_PRELOAD 檢測(cè)內(nèi)存泄漏，我們可以在不修改程序源代碼的情況下，動(dòng)態(tài)地改變程序的行為，記錄內(nèi)存分配和釋放的信息，從而檢測(cè)到內(nèi)存泄漏并找出內(nèi)存泄漏的來源。

1.3 小結(jié)

最后我們以一個(gè)表格總結(jié)一下本節(jié)的三種代理實(shí)現(xiàn)方式的優(yōu)缺點(diǎn)：

二、檢測(cè)Natie內(nèi)存泄露

本節(jié)我們將基于PLT/GOT Hook的代理實(shí)現(xiàn)方案，介紹檢測(cè)Native層內(nèi)存泄漏的整體思路。

2.1 原理介紹

在Android中，要檢測(cè)Native層的內(nèi)存泄漏，可以重寫malloc、calloc、realloc和free等內(nèi)存分配和釋放函數(shù)，以便在每次分配和釋放內(nèi)存時(shí)記錄相關(guān)信息。例如，我們可以創(chuàng)建一個(gè)全局的內(nèi)存分配表，用于存儲(chǔ)所有分配的內(nèi)存塊及其元數(shù)據(jù)（如分配大小、分配位置等）。然后，在釋放內(nèi)存時(shí)，從內(nèi)存分配表中刪除相應(yīng)的條目。定期檢查內(nèi)存分配表，找出沒有被釋放的內(nèi)存。

2.2 代碼示例

下面代碼的主要技術(shù)原理是重寫內(nèi)存管理函數(shù)，并使用弱符號(hào)引用原始的內(nèi)存管理函數(shù)，以便在每次分配和釋放內(nèi)存時(shí)記錄相關(guān)信息，并能夠在程序運(yùn)行時(shí)動(dòng)態(tài)地查找和調(diào)用這些函數(shù)。

以下是代碼示例：

#include <cstdlib>
#include <cstdio>
#include <map>
#include <mutex>
#include <dlfcn.h>
#include <execinfo.h>
#include <vector>
#include <android/log.h>  

#define TAG "CheckMemoryLeaks" 
#define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, TAG, __VA_ARGS__)

// 全局內(nèi)存分配表，存儲(chǔ)分配的內(nèi)存塊及其元數(shù)據(jù)（如分配大小、調(diào)用棧等）
std::map<void*, std::pair<size_t, std::vector<void*>>> g_memoryAllocations;
std::mutex g_memoryAllocationsMutex;

// 定義弱符號(hào)引用原始的內(nèi)存管理函數(shù)
extern "C" void* __libc_malloc(size_t size) __attribute__((weak));
extern "C" void  __libc_free(void* ptr) __attribute__((weak));
extern "C" void* __libc_realloc(void *ptr, size_t size) __attribute__((weak));
extern "C" void* __libc_calloc(size_t nmemb, size_t size) __attribute__((weak));

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

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

// 在分配內(nèi)存時(shí)記錄調(diào)用棧
std::vector<void*> record_call_stack() {
  //  ...
}

// 初始化原始內(nèi)存管理函數(shù)，如果弱符號(hào)未定義，則使用 dlsym 獲取函數(shù)地址
void init_original_functions() {
  if (!lt_malloc) {
    if (__libc_malloc) {
      lt_malloc = __libc_malloc;
    } else {
      lt_malloc = (void*(*)(size_t))dlsym(RTLD_NEXT, "malloc");
    }
  }
  //calloc realloc free 的實(shí)現(xiàn)也類似
  ...
}

// 重寫 malloc 函數(shù)
extern "C" void* malloc(size_t size) {
  // 初始化原始內(nèi)存管理函數(shù)
  init_original_functions();

  // 調(diào)用原始的 malloc 函數(shù)
  void* ptr = LT_MALLOC(size);

  // 記錄調(diào)用棧
  std::vector<void*> call_stack = record_call_stack();

  // 在全局內(nèi)存分配表中添加新分配的內(nèi)存塊及其元數(shù)據(jù)
  std::unique_lock<std::mutex> lock(g_memoryAllocationsMutex);
  g_memoryAllocations[ptr] = std::make_pair(size, call_stack);

  return ptr;
}

// 重寫 calloc 函數(shù)
extern "C" void* calloc(size_t nmemb, size_t size) {
  // 跟 malloc 實(shí)現(xiàn)類似
  // ...
}

// 重寫 realloc 函數(shù)
extern "C" void* realloc(void* ptr, size_t size) {
  // 初始化原始內(nèi)存管理函數(shù)
  init_original_functions();

  // 調(diào)用原始的 realloc 函數(shù)
  void* newPtr = LT_REALLOC(ptr, size);

  // 記錄調(diào)用棧
  std::vector<void*> call_stack = record_call_stack();
  
  // 更新全局內(nèi)存分配表中的內(nèi)存塊及其元數(shù)據(jù)
  std::unique_lock<std::mutex> lock(g_memoryAllocationsMutex);
  g_memoryAllocations.erase(ptr);
  g_memoryAllocations[newPtr] = std::make_pair(size, call_stack);

  return newPtr;
}

// 重寫 free 函數(shù)
extern "C" void free(void* ptr) {
  // 初始化原始內(nèi)存管理函數(shù)
  init_original_functions();

  // 從全局內(nèi)存分配表中刪除釋放的內(nèi)存塊
  std::unique_lock<std::mutex> lock(g_memoryAllocationsMutex);
  g_memoryAllocations.erase(ptr);

  // 調(diào)用原始的 free 函數(shù)
  LT_FREE(ptr);
}

// 定義一個(gè)函數(shù)用于檢查內(nèi)存泄漏
void check_memory_leaks() {
  // 使用互斥鎖保護(hù)對(duì)全局內(nèi)存分配表的訪問，防止在多線程環(huán)境下發(fā)生數(shù)據(jù)競(jìng)爭(zhēng)
  std::unique_lock<std::mutex> lock(g_memoryAllocationsMutex);

  // 如果全局內(nèi)存分配表為空，說明沒有檢測(cè)到內(nèi)存泄漏
  if (g_memoryAllocations.empty()) {
    LOGD("No memory leaks detected.");
  } else {
    // 如果全局內(nèi)存分配表不為空，說明檢測(cè)到了內(nèi)存泄漏
    LOGD("Memory leaks detected:");
    // 遍歷全局內(nèi)存分配表，打印出所有未被釋放的內(nèi)存塊的地址和大小
    for (const auto& entry : g_memoryAllocations) {
      LOGD("  Address: %p, Size: %zu bytes\n", entry.first, entry.second.first);
      LOGD("  Call stack:");
      for (void* frame : entry.second.second) {
        LOGD("    %p\n", frame);
      }
    }
  }
}

int main() {
  // 初始化原始內(nèi)存管理函數(shù)
  init_original_functions();
  
  // 示例代碼
  void* ptr1 = malloc(10);
  void* ptr2 = calloc(10, sizeof(int));
  void* ptr3 = malloc(20);
  ptr3 = realloc(ptr3, 30);
  free(ptr1);
  free(ptr2);
  free(ptr3);

  // 檢查內(nèi)存泄漏
  check_memory_leaks();

  return 0;
}

上面代碼的核心邏輯包括：

重寫內(nèi)存管理函數(shù)：重寫malloc、calloc、realloc和free，在分配內(nèi)存時(shí)將內(nèi)存塊及其信息添加到全局內(nèi)存分配表，釋放內(nèi)存時(shí)從表中刪除相應(yīng)內(nèi)存塊。
弱符號(hào)引用原始內(nèi)存管理函數(shù)：使用__attribute__((weak))定義四個(gè)弱符號(hào)引用glibc/eglibc中的內(nèi)存管理函數(shù)。在init_original_functions函數(shù)中檢查弱符號(hào)定義，若未定義則使用dlsym函數(shù)查找原始內(nèi)存管理函數(shù)。
全局內(nèi)存分配表：定義全局內(nèi)存分配表存儲(chǔ)所有分配的內(nèi)存塊及其信息。表是一個(gè)map，鍵是內(nèi)存塊地址，值是一個(gè)pair，包含內(nèi)存塊大小和調(diào)用棧。
調(diào)用棧記錄：分配內(nèi)存時(shí)記錄當(dāng)前調(diào)用棧，有助于檢測(cè)內(nèi)存泄漏時(shí)找出泄漏來源。
內(nèi)存泄漏檢測(cè)：定義check_memory_leaks函數(shù)檢查全局內(nèi)存分配表中仍存在的內(nèi)存塊，表示存在內(nèi)存泄漏。

2.2.1 使用弱符號(hào)：防止對(duì)`dlsym`函數(shù)的調(diào)用導(dǎo)致無限遞歸

dlsym函數(shù)用于查找動(dòng)態(tài)鏈接庫(kù)中的符號(hào)。但是在glibc和eglibc中，dlsym函數(shù)內(nèi)部可能會(huì)調(diào)用calloc函數(shù)。如果我們正在重定義calloc函數(shù)，并且在calloc函數(shù)中調(diào)用dlsym函數(shù)來獲取原始的calloc函數(shù)，那么就會(huì)產(chǎn)生無限遞歸。

__libc_calloc等函數(shù)被聲明為弱符號(hào)，這是為了避免與glibc或eglibc中對(duì)這些函數(shù)的強(qiáng)符號(hào)定義產(chǎn)生沖突。然后在init_original_functions函數(shù)中，我們檢查了__libc_calloc等函數(shù)是否為nullptr。如果是，那么說明glibc或eglibc沒有定義這些函數(shù)，那就使用dlsym函數(shù)獲取這些函數(shù)的地址。如果不是，那么說明glibc或eglibc已經(jīng)定義了這些函數(shù)，那就直接使用那些定義。

2.2.2 關(guān)于RTLD_NEXT的解釋

RTLD_NEXT是一個(gè)特殊的“偽句柄”，用于在動(dòng)態(tài)鏈接庫(kù)函數(shù)中查找下一個(gè)符號(hào)。它常常與dlsym函數(shù)一起使用，用于查找和調(diào)用原始的（被覆蓋或者被截獲的）函數(shù)。

在Linux系統(tǒng)中，如果一個(gè)程序鏈接了多個(gè)動(dòng)態(tài)鏈接庫(kù)，而這些庫(kù)中有多個(gè)定義了同名的函數(shù)，那么在默認(rèn)情況下，程序會(huì)使用第一個(gè)找到的函數(shù)。但有時(shí)候，我們可能需要在一個(gè)庫(kù)中覆蓋另一個(gè)庫(kù)中的函數(shù)，同時(shí)又需要調(diào)用原始的函數(shù)。這時(shí)候就可以使用RTLD_NEXT。

dlsym(RTLD_NEXT, "malloc")會(huì)查找下一個(gè)名為"malloc"的符號(hào)，即原始的malloc函數(shù)。然后我們就可以在自定義的malloc函數(shù)中調(diào)用原始的malloc函數(shù)了。

2.2.3 注意事項(xiàng)

檢測(cè)內(nèi)存泄漏可能會(huì)增加程序的運(yùn)行時(shí)開銷，并可能導(dǎo)致一些與線程安全相關(guān)的問題。在使用這種方法時(shí)，我們需要確保代碼是線程安全的，并在不影響程序性能的情況下進(jìn)行內(nèi)存泄漏檢測(cè)。同時(shí)，手動(dòng)檢測(cè)內(nèi)存泄漏可能無法發(fā)現(xiàn)所有的內(nèi)存泄漏，因此建議大家還要使用其他工具（如AddressSanitizer、LeakSanitizer或Valgrind）來輔助檢測(cè)內(nèi)存泄漏。

三、獲取Android Native堆棧

大家可能也注意到了，在第二部分的Native內(nèi)存泄露檢測(cè)實(shí)現(xiàn)中，record_call_stack的實(shí)現(xiàn)省略了。所以我們還遺留了一個(gè)問題：應(yīng)該如何記錄分配內(nèi)存時(shí)的調(diào)用棧呢？最后一節(jié)我們就來闡述獲取Android Native堆棧的方法。

3.1 使用`unwind`函數(shù)

3.1.1 工具和方法

對(duì)于Android系統(tǒng)，不能直接使用backtrace_symbols函數(shù)，因?yàn)樗贏ndroid Bionic libc中沒有實(shí)現(xiàn)。但是，我們可以使用dladdr函數(shù)替代backtrace_symbols來獲取符號(hào)信息。

Android NDK提供了unwind.h頭文件，其中定義了unwind函數(shù)，可以用于獲取任意線程的堆棧信息。

3.1.2 獲取當(dāng)前線程的堆棧信息

如果我們需要獲取當(dāng)前線程的堆棧信息，可以使用Android NDK中的unwind函數(shù)。以下是使用unwind函數(shù)獲取堆棧信息的示例代碼：

#include <unwind.h>
#include <dlfcn.h>
#include <stdio.h>

// 定義一個(gè)結(jié)構(gòu)體，用于存儲(chǔ)回溯狀態(tài)
struct BacktraceState {
    void** current;
    void** end;
};

// 回溯回調(diào)函數(shù)，用于處理每一幀的信息
_Unwind_Reason_Code unwind_callback(struct _Unwind_Context* context, void* arg) {
    BacktraceState* state = static_cast<BacktraceState*>(arg);
    uintptr_t pc = _Unwind_GetIP(context);
    if (pc) {
        if (state->current == state->end) {
            return _URC_END_OF_STACK;
        } else {
            *state->current++ = reinterpret_cast<void*>(pc);
        }
    }
    return _URC_NO_REASON;
}

// 捕獲回溯信息，將其存儲(chǔ)到buffer中
void capture_backtrace(void** buffer, int max) {
    BacktraceState state = {buffer, buffer + max};
    _Unwind_Backtrace(unwind_callback, &state);
}

// 打印回溯信息
void print_backtrace(void** buffer, int count) {
    for (int idx = 0; idx < count; ++idx) {
        const void* addr = buffer[idx];
        const char* symbol = "";

        Dl_info info;
        if (dladdr(addr, &info) && info.dli_sname) {
            symbol = info.dli_sname;
        }

        // 計(jì)算相對(duì)地址
        void* relative_addr = reinterpret_cast<void*>(reinterpret_cast<uintptr_t>(addr) - reinterpret_cast<uintptr_t>(info.dli_fbase));

        printf("%-3d %p %s (relative addr: %p)\n", idx, addr, symbol, relative_addr);
    }
}

// 主函數(shù)
int main() {
    const int max_frames = 128;
    void* buffer[max_frames];

    // 捕獲回溯信息
    capture_backtrace(buffer, max_frames);
    // 打印回溯信息
    print_backtrace(buffer, max_frames);

    return 0;
}

在上述代碼中，capture_backtrace函數(shù)使用_Unwind_Backtrace函數(shù)獲取堆棧信息，然后我們使用dladdr函數(shù)獲取到函數(shù)所在的SO庫(kù)的基地址（info.dli_fbase），然后計(jì)算出函數(shù)的相對(duì)地址（relative_addr）。然后在打印堆棧信息時(shí)，同時(shí)打印出函數(shù)的相對(duì)地址。

3.1.3 libunwind的相關(guān)接口

3.1.3.1 _Unwind_Backtrace

_Unwind_Backtrace是libunwind庫(kù)的函數(shù)，用于獲取當(dāng)前線程調(diào)用堆棧。它遍歷棧幀并在每個(gè)棧幀上調(diào)用用戶定義的回調(diào)函數(shù)，以獲取棧幀信息（如函數(shù)地址、參數(shù)等）。函數(shù)原型如下：

_Unwind_Reason_Code _Unwind_Backtrace(_Unwind_Trace_Fn trace, void *trace_argument);

參數(shù)：

trace：回調(diào)函數(shù)，會(huì)在每個(gè)堆棧幀上被調(diào)用?；卣{(diào)函數(shù)需返回_Unwind_Reason_Code類型值，表示執(zhí)行結(jié)果。
trace_argument：用戶自定義參數(shù)，傳遞給回調(diào)函數(shù)。通常用于存儲(chǔ)堆棧信息或其他用戶數(shù)據(jù)。

3.1.3.2 _Unwind_GetIP

_Unwind_GetIP是libunwind庫(kù)的函數(shù)，用于獲取當(dāng)前棧幀的指令指針（即當(dāng)前函數(shù)的返回地址）。它依賴底層硬件架構(gòu)（如ARM、x86等）和操作系統(tǒng)實(shí)現(xiàn)。函數(shù)原型如下：

uintptr_t _Unwind_GetIP(struct _Unwind_Context *context);

參數(shù)：

context：當(dāng)前棧幀的上下文信息。在_Unwind_Backtrace函數(shù)中創(chuàng)建并在每個(gè)棧幀上傳遞給回調(diào)函數(shù)。

_Unwind_GetIP返回?zé)o符號(hào)整數(shù)，表示當(dāng)前函數(shù)的返回地址?？捎么说刂帆@取函數(shù)的符號(hào)信息，如函數(shù)名、源文件名和行號(hào)等。

3.1.3.3 在不同Android版本中的可用性

_Unwind_Backtrace和_Unwind_GetIP函數(shù)在libunwind庫(kù)中定義，該庫(kù)是GNU C Library（glibc）的一部分。但Android系統(tǒng)使用輕量級(jí)的C庫(kù)Bionic libc，而非glibc。因此，這兩個(gè)函數(shù)在Android系統(tǒng)中的可用性取決于Bionic libc和Android系統(tǒng)版本。

在早期Android版本（如Android 4.x），Bionic libc未完全實(shí)現(xiàn)libunwind庫(kù)功能，導(dǎo)致_Unwind_Backtrace和_Unwind_GetIP函數(shù)可能無法正常工作。這時(shí)，需使用其他方法獲取堆棧信息，如手動(dòng)遍歷棧幀或使用第三方庫(kù)。

從Android 5.0（Lollipop）起，Bionic libc提供更完整的libunwind庫(kù)支持，包括_Unwind_Backtrace和_Unwind_GetIP函數(shù)。因此，在Android 5.0及更高版本中，可直接使用這兩個(gè)函數(shù)獲取堆棧信息。

盡管這兩個(gè)函數(shù)在新版Android系統(tǒng)中可用，但它們的行為可能受編譯器優(yōu)化、調(diào)試信息等影響。實(shí)際使用中，我們需要根據(jù)具體情況選擇最合適的方法。

3.2 手動(dòng)遍歷棧幀來實(shí)現(xiàn)獲取堆棧信息

在Android系統(tǒng)中，_Unwind_Backtrace的具體實(shí)現(xiàn)依賴于底層硬件架構(gòu)（例如ARM、x86等）和操作系統(tǒng)。它會(huì)使用特定于架構(gòu)的寄存器和數(shù)據(jù)結(jié)構(gòu)來遍歷棧幀。例如，在ARM64架構(gòu)上，_Unwind_Backtrace會(huì)使用Frame Pointer（FP）寄存器和Link Register（LR）寄存器來遍歷棧幀。

如果不使用_Unwind_Backtrace，我們可以手動(dòng)遍歷棧幀來實(shí)現(xiàn)獲取堆棧信息。

3.2.1 ARM64架構(gòu)下的示例代碼

以下是一個(gè)基于ARM64架構(gòu)的示例代碼，展示如何使用Frame Pointer（FP）寄存器手動(dòng)遍歷棧幀：

#include <stdio.h>
#include <dlfcn.h>

void print_backtrace_manual() {
    uintptr_t fp = 0;
    uintptr_t lr = 0;

    // 獲取當(dāng)前的FP和LR寄存器值
    asm("mov %0, x29" : "=r"(fp));
    asm("mov %0, x30" : "=r"(lr));

    while (fp) {
        // 計(jì)算上一個(gè)棧幀的FP和LR寄存器值
        uintptr_t prev_fp = *(uintptr_t*)(fp);
        uintptr_t prev_lr = *(uintptr_t*)(fp + 8);

        // 獲取函數(shù)地址對(duì)應(yīng)的符號(hào)信息
        Dl_info info;
        if (dladdr(reinterpret_cast<void*>(lr), &info) && info.dli_sname) {
            printf("%p %s\n", reinterpret_cast<void*>(lr), info.dli_sname);
        } else {
            printf("%p\n", reinterpret_cast<void*>(lr));
        }

        // 更新FP和LR寄存器值
        fp = prev_fp;
        lr = prev_lr;
    }
}

在上述代碼中，我們首先獲取當(dāng)前的FP（x29）和LR（x30）寄存器值。然后，通過遍歷FP鏈，獲取每個(gè)棧幀的返回地址（存儲(chǔ)在LR寄存器中）。最后，使用dladdr函數(shù)獲取函數(shù)地址對(duì)應(yīng)的符號(hào)信息，并打印堆棧信息。

在這段代碼中，*(uintptr_t*)(fp)表示的是取fp所指向的內(nèi)存地址處的值。fp是一個(gè)無符號(hào)整數(shù)，表示的是一個(gè)內(nèi)存地址，(uintptr_t*)(fp)將fp轉(zhuǎn)換成一個(gè)指針，然后*操作符取該指針?biāo)赶虻闹怠?/p>

在ARM64架構(gòu)中，函數(shù)調(diào)用時(shí)會(huì)創(chuàng)建一個(gè)新的棧幀。每個(gè)棧幀中包含了函數(shù)的局部變量、參數(shù)、返回地址以及其他與函數(shù)調(diào)用相關(guān)的信息。其中，F(xiàn)rame Pointer（FP，幀指針）寄存器（x29）保存了上一個(gè)棧幀的FP寄存器值，Link Register（LR）寄存器（x30）保存了函數(shù)的返回地址。

在這段代碼中，fp變量保存了當(dāng)前棧幀的FP寄存器值，也就是上一個(gè)棧幀的幀基址。因此，*(uintptr_t*)(fp)取的就是上一個(gè)棧幀的FP寄存器值，即上上個(gè)棧幀的幀基址。這個(gè)值在遍歷棧幀時(shí)用來更新fp變量，以便在下一次循環(huán)中處理上一個(gè)棧幀。

3.2.2 ARM架構(gòu)下的示例代碼

在ARM架構(gòu)下，我們可以使用Frame Pointer（FP）寄存器（R11）和Link Register（LR）寄存器（R14）來手動(dòng)遍歷棧幀。以下是一個(gè)基于ARM架構(gòu)的示例代碼，展示如何手動(dòng)遍歷棧幀以獲取堆棧信息：

#include <stdio.h>
#include <dlfcn.h>

void print_backtrace_manual_arm() {
    uintptr_t fp = 0;
    uintptr_t lr = 0;

    // 獲取當(dāng)前的FP和LR寄存器值
    asm("mov %0, r11" : "=r"(fp));
    asm("mov %0, r14" : "=r"(lr));

    while (fp) {
        // 計(jì)算上一個(gè)棧幀的FP和LR寄存器值
        uintptr_t prev_fp = *(uintptr_t*)(fp);
        uintptr_t prev_lr = *(uintptr_t*)(fp + 4);

        // 獲取函數(shù)地址對(duì)應(yīng)的符號(hào)信息
        Dl_info info;
        if (dladdr(reinterpret_cast<void*>(lr), &info) && info.dli_sname) {
            printf("%p %s\n", reinterpret_cast<void*>(lr), info.dli_sname);
        } else {
            printf("%p\n", reinterpret_cast<void*>(lr));
        }

        // 更新FP和LR寄存器值
        fp = prev_fp;
        lr = prev_lr;
    }
}

在這個(gè)示例代碼中，我們首先獲取當(dāng)前的FP（R11）和LR（R14）寄存器值。然后，通過遍歷FP鏈，獲取每個(gè)棧幀的返回地址（存儲(chǔ)在LR寄存器中）。最后，使用dladdr函數(shù)獲取函數(shù)地址對(duì)應(yīng)的符號(hào)信息，并打印堆棧信息。

通過以上示例代碼，我們可以看到，在不同架構(gòu)上手動(dòng)遍歷棧幀以獲取堆棧信息的方法大致相同，只是寄存器和數(shù)據(jù)結(jié)構(gòu)有所不同。這種方法提供了一種在不使用_Unwind_Backtrace的情況下獲取堆棧信息的方式，有助于我們更好地理解和調(diào)試程序。

3.2.3 寄存器

在函數(shù)調(diào)用過程中，fp（Frame Pointer，幀指針）、lr（Link Register，鏈接寄存器）和sp（Stack Pointer，棧指針）是三個(gè)關(guān)鍵寄存器，它們之間的關(guān)系如下：

fp（Frame Pointer）：幀指針寄存器用于指向當(dāng)前棧幀的幀基址。在函數(shù)調(diào)用過程中，每個(gè)函數(shù)都會(huì)有一個(gè)棧幀，用于存儲(chǔ)函數(shù)的局部變量、參數(shù)、返回地址等信息。fp寄存器有助于定位和訪問這些信息。在不同的架構(gòu)中，fp寄存器可能有不同的名稱，例如，在ARM64架構(gòu)中，fp寄存器對(duì)應(yīng)X29；在ARM架構(gòu)中，fp寄存器對(duì)應(yīng)R11；在x86_64架構(gòu)中，fp寄存器對(duì)應(yīng)RBP。
lr（Link Register）：鏈接寄存器用于保存函數(shù)的返回地址。當(dāng)一個(gè)函數(shù)被調(diào)用時(shí)，程序需要知道在函數(shù)執(zhí)行完畢后返回到哪里繼續(xù)執(zhí)行。這個(gè)返回地址就被保存在lr寄存器中。在不同的架構(gòu)中，lr寄存器可能有不同的名稱，例如，在ARM64架構(gòu)中，lr寄存器對(duì)應(yīng)X30；在ARM架構(gòu)中，lr寄存器對(duì)應(yīng)R14；在x86_64架構(gòu)中，返回地址通常被保存在棧上，而不是專用寄存器中。
sp（Stack Pointer）：棧指針寄存器用于指向當(dāng)前棧幀的棧頂。在函數(shù)調(diào)用過程中，棧指針會(huì)根據(jù)需要分配或釋放?？臻g。在不同的架構(gòu)中，sp寄存器可能有不同的名稱，例如，在ARM64架構(gòu)中，sp寄存器對(duì)應(yīng)XSP；在ARM架構(gòu)中，sp寄存器對(duì)應(yīng)R13；在x86_64架構(gòu)中，sp寄存器對(duì)應(yīng)RSP。

fp、lr和sp三者在函數(shù)調(diào)用過程中共同協(xié)作，以實(shí)現(xiàn)正確的函數(shù)調(diào)用和返回。fp用于定位棧幀中的數(shù)據(jù)，lr保存函數(shù)的返回地址，而sp則負(fù)責(zé)管理?xiàng)？臻g。在遍歷棧幀以獲取堆棧信息時(shí)，我們需要利用這三個(gè)寄存器之間的關(guān)系來定位每個(gè)棧幀的位置和內(nèi)容。

3.2.4 棧幀

棧幀（Stack Frame）是函數(shù)調(diào)用過程中的一個(gè)重要概念。每次函數(shù)調(diào)用時(shí)，都會(huì)在棧上創(chuàng)建一個(gè)新的棧幀。棧幀包含了函數(shù)的局部變量、參數(shù)、返回地址以及其他一些與函數(shù)調(diào)用相關(guān)的信息。下圖是一個(gè)標(biāo)準(zhǔn)的函數(shù)調(diào)用過程：

EBP：基址指針寄存器，指向棧幀的底部。在 ARM 下寄存器為 R11。在 ARM64 中寄存器為 X29。ESP：棧指針寄存器，指向棧幀的棧頂，在 ARM 下寄存器為 R13。EIP：指令寄存器，存儲(chǔ)的是 CPU 下次要執(zhí)行的指令的地址，ARM 下為 PC，寄存器為 R15。

每次函數(shù)調(diào)用都會(huì)保存 EBP 和 EIP 用于在返回時(shí)恢復(fù)函數(shù)棧幀。這里所有被保存的 EBP 就像一個(gè)鏈表指針，不斷地指向調(diào)用函數(shù)的 EBP。

在Android系統(tǒng)中，棧幀的基本原理與其他操作系統(tǒng)相同，通過SP和FP所限定的stack frame，就可以得到母函數(shù)的SP和FP，從而得到母函數(shù)的stack frame（PC，LR，SP，F(xiàn)P會(huì)在函數(shù)調(diào)用的第一時(shí)間壓棧），以此追溯，即可得到所有函數(shù)的調(diào)用順序。

在ARM64和ARM架構(gòu)中，我們可以使用FP鏈（幀指針鏈）來遍歷棧幀。具體方法是：從當(dāng)前FP寄存器開始，沿著FP鏈向上遍歷，直到遇到空指針（NULL）或者無效地址。在遍歷過程中，我們可以從每個(gè)棧幀中提取返回地址（存儲(chǔ)在LR寄存器中）以及其他相關(guān)信息。

3.2.5 名字修飾（Name Mangling）

Native堆棧的符號(hào)信息跟代碼中定義的函數(shù)名字相比，可能會(huì)有一些差別，因?yàn)镚CC生成的符號(hào)表有一些修飾規(guī)則。

C++支持函數(shù)重載，即同一個(gè)函數(shù)名可以有不同的參數(shù)類型和個(gè)數(shù)。為了在編譯時(shí)區(qū)分這些函數(shù)，GCC會(huì)對(duì)函數(shù)名進(jìn)行修飾，生成獨(dú)特的符號(hào)名稱。修飾后的名稱包含了函數(shù)名、參數(shù)類型等信息。例如，對(duì)于如下C++函數(shù)：

namespace test {
  int foo(int a, double b);
}

經(jīng)過GCC修飾后，生成的符號(hào)可能類似于：_ZN4test3fooEid，其中：

_ZN和E是修飾前綴和后綴，用于標(biāo)識(shí)這是一個(gè)C++符號(hào)。
4test表示命名空間名為test，4表示命名空間名的長(zhǎng)度。
3foo表示函數(shù)名為foo，3表示函數(shù)名的長(zhǎng)度。
id表示函數(shù)的參數(shù)類型，i代表int，d代表double。

四、實(shí)踐建議

通過前文的詳細(xì)介紹，我們已經(jīng)了解了如何實(shí)現(xiàn)Android Native內(nèi)存泄漏監(jiān)控的三個(gè)方面：包括代理實(shí)現(xiàn)、檢測(cè)Native內(nèi)存泄露和獲取Android Native堆棧的方法。最后，我們?cè)賮砜匆幌卢F(xiàn)有的一些內(nèi)存泄露檢測(cè)工具對(duì)比，并給出一些實(shí)踐建議。

4.1 Native 內(nèi)存泄露檢測(cè)工具對(duì)比

在實(shí)際應(yīng)用中，我們需要根據(jù)具體場(chǎng)景選擇最合適的方案。下面表格中的前三種工具都是現(xiàn)成的，但是具有一定的局限性，特別是不適合在線上使用。

4.2 實(shí)踐建議

在實(shí)際項(xiàng)目中，我們可以結(jié)合多種內(nèi)存泄漏檢測(cè)方案來提高檢測(cè)效果。以下是一些建議：

編碼規(guī)范：在編寫代碼時(shí)，遵循一定的編碼規(guī)范和最佳實(shí)踐，例如使用智能指針、避免循環(huán)引用等，可以有效地降低內(nèi)存泄漏的風(fēng)險(xiǎn)。
代碼審查：在開發(fā)過程中，定期進(jìn)行代碼審查，檢查代碼中是否存在潛在的內(nèi)存泄漏風(fēng)險(xiǎn)。代碼審查可以幫助我們及時(shí)發(fā)現(xiàn)和修復(fù)問題，提高代碼質(zhì)量。
自動(dòng)化測(cè)試：在項(xiàng)目中引入自動(dòng)化測(cè)試，對(duì)關(guān)鍵功能進(jìn)行內(nèi)存泄漏檢測(cè)?？梢栽诔掷m(xù)集成環(huán)境中使用ASan、LSan等工具來檢測(cè)內(nèi)存泄漏，確保新提交的代碼不會(huì)引入新的內(nèi)存泄漏問題。
性能監(jiān)控：在線上環(huán)境中，定期監(jiān)控應(yīng)用程序的內(nèi)存使用情況。如果發(fā)現(xiàn)內(nèi)存使用異常，可以使用手動(dòng)檢測(cè)方法或者將問題反饋到開發(fā)環(huán)境，使用其他工具進(jìn)行進(jìn)一步分析和處理。
問題定位：當(dāng)發(fā)現(xiàn)內(nèi)存泄漏問題時(shí)，根據(jù)工具提供的錯(cuò)誤信息，快速定位問題發(fā)生的位置。結(jié)合堆棧信息、相對(duì)地址等，可以幫助我們更好地理解問題的原因，從而修復(fù)問題。

五、總結(jié)

在開發(fā)和測(cè)試階段，我們可以使用ASan、LSan和Valgrind等工具來檢測(cè)內(nèi)存泄漏。而在線上環(huán)境中，由于這些工具的性能開銷較大，不適合直接使用。在這種情況下，我們可以采用手動(dòng)檢測(cè)的方法，結(jié)合代碼審查和良好的編程習(xí)慣，來盡可能地減少內(nèi)存泄漏的發(fā)生。

然而，這些工具并不能保證檢測(cè)出所有的內(nèi)存泄漏。內(nèi)存泄漏的發(fā)現(xiàn)和修復(fù)，需要我們對(duì)代碼有深入的理解，以及良好的編程習(xí)慣。只有這樣，我們才能有效地防止和解決內(nèi)存泄漏問題，從而提高我們的應(yīng)用程序的穩(wěn)定性和性能。

Android Native內(nèi)存泄漏檢測(cè)方案詳解

一、代理內(nèi)存管理函數(shù)實(shí)現(xiàn)