重现步骤：

1. 将demo工程目录下的build.gradle的版本号改为3.6.0或以上，如：

dependencies {
        classpath 'com.android.tools.build:gradle:4.1.2'
        classpath 'com.github.dcendents:android-maven-gradle-plugin:2.1'
}

2. 将gradle-wrapper.properties的Url改为6.8.3，如：

distributionUrl=https\://services.gradle.org/distributions/gradle-6.8.3-all.zip

3. gradle-wrapper.jar无需修改
4. 将demo/build.gradle中的minSdkVersion改为23

defaultConfig {
    minSdkVersion 23
    targetSdkVersion 28
}

5. 在Raphael.start中将so列表改为libtester.so（仅为了方便问题定位）

Raphael.start(Raphael.MAP64_MODE|Raphael.ALLOC_MODE|0x0F0000|1024, space, "libtester.so");

6. 添加测试工程，用于内存申请
7. 重新编译并运行demo工程 如上修改均已完成，地址：https://github.com/huchao/memory-leak-detector 【案例1】直接编译运行后，点击界面上的Malloc按钮，然后点击打印按钮，最终并没有Hook到malloc调用。 【案例2】在App的AndroidManifest.xml中的Application中添加android:extractNativeLibs="true"配置禁用uncompress属性后，重新编译运行案例1，report文件中能够找到malloc调用。

0x72e516e000, 1024, 1
0x000006A4 /data/app/~~KhDIb1J0OYri3Rjwjas_nA==/com.bytedance.raphael.demo-mSCPf4jfHg_fgGGIxGcAdw==/lib/arm64/libtester.so (Java_com_huchao_jni_Heap_malloc + ?)
0x00012ED8 /apex/com.android.art/lib64/libart.so (unknown)
0x00012ED8 <unknown> (unknown)

【问题原因】Android系统6.0+版本，Android Gradle Plugin 3.6.0+版本引入了so uncompress特性，并且默认开启，开启后，so以非压缩方式被打包到apk中，load so时，将从apk中直接load入内存，无需解压。这也就导致xh_core_refresh中，查找/proc/[pid]/maps时正则匹配不到对应的so，最终整套PLT Hook逻辑无法运行。 图中摘抄了maps的libtester.so部分，可见原有的/lib/arm64/libtester.so被替换为base.apk了，并且offset也不为0了，无法通过这个来判断ELF Header了。

当address != NULL, ptr == NULL, size == 0时，realloc不做任何事情，仅返回base address。当前的方案会bad remove, bad insert 当address != NULL, ptr != NULL, size != 0时，realloc成功，需要先删除原有信息，然后再更新。当前的方案仅会insert。 原有代码size >= limit也有问题，如：size == 0，limit == 1024，可能走到realloc equal to free逻辑，需要remove，代码会被跳过。 另外，我的新代码也存在Bug，如果realloc size < limit，则会被跳过，此逻辑问题好像无法解决。 https://man7.org/linux/man-pages/man3/free.3.html

MemoryCache.cpp 中 pthread_mutex_lock(&alloc_mutex); for (auto p : alloc_table) { for (; p != nullptr; p = p->next) { write_trace(report, p, nullptr, &dl_cache); } } pthread_mutex_lock(&alloc_mutex);

pthread_mutex_lock(&alloc_mutex); 在调试中发现这句代码卡住线程

Raphael script version: 1.0.0 Traceback (most recent call last): File "library/src/main/python/raphael.py", line 215, in report = parse_report(string) File "library/src/main/python/raphael.py", line 183, in parse_report report.append(Trace(match[0][0], match[0][1], match[0][2], stack)) IndexError: list index out of range

Raphael.MAP64_MODE | Raphael.ALLOC_MODE | 0x0F0000 | 1024 前两个mode我大概可以猜到是什么，一个是监听 MMAP，一个是监听 ALLOC，查看源码我看到还有一个 DIFF_CACHE，这是什么含义？ 后面的 0x0F0000 和 1024 又是配置的什么？

extern "C" JNIEXPORT void JNICALL
Java_com_xxxx_filament_ObjAssimpLoader_nLoad(JNIEnv *env, jclass, jstring path, jlong nativeEngine) {
    g_meshSet = std::make_unique<ObjMeshAssimp>(*((Engine*)nativeEngine));
    utils::Path filename = env->GetStringUTFChars(path, 0);
    g_meshSet->addFromFile(filename, g_materialInstances, true);
    //人为制造一个内存泄漏对象
    std::unique_ptr<ObjMeshAssimp> temp = std::make_unique<ObjMeshAssimp>(*((Engine*)nativeEngine));
}

大佬，问下，我集成这个工具后，生成report，并没有找到我泄漏的so代码行号，唯一相关的so信息如下：

0x00000076e2647000, 4096, 1
0x0000000000214cc0 /data/app/com.xxxx.filament.textured-OlqQ08eyhNALYGjMKOUN6w==/lib/arm64/libfilament_jni.so (std::__ndk1::deque<unsigned int, std::__ndk1::allocator<unsigned int> >::__add_back_capacity())

0x00000076e2ba9000, 4096, 1
0x00000000003127c8 /system/lib64/libart.so (art::jit::JitCodeCache::AddProfilingInfoInternal(art::Thread*, art::ArtMethod*, std::__1::vector<unsigned int, std::__1::allocator<unsigned int> > const&) + 276)
0x0000000000312680 /system/lib64/libart.so (art::jit::JitCodeCache::AddProfilingInfo(art::Thread*, art::ArtMethod*, std::__1::vector<unsigned int, std::__1::allocator<unsigned int> > const&, bool) + 132)
0x0000000000322c14 /system/lib64/libart.so (art::ProfilingInfo::Create(art::Thread*, art::ArtMethod*, bool) + 372)
0x0000000000309040 /system/lib64/libart.so (art::jit::Jit::AddSamples(art::Thread*, art::ArtMethod*, unsigned short, bool) + 504)
0x0000000000280394 /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*) + 180)
0x000000000027a444 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*) + 972)
0x0000000000526f0c /system/lib64/libart.so (MterpInvokeVirtual + 592)
0x000000000054a598 /system/lib64/libart.so (ExecuteMterpImpl + 14232)
0x0000000000254148 /system/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool) (.llvm.3404100416) + 492)
0x0000000000259c3c /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*) + 220)
0x000000000027a428 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*) + 944)
0x0000000000526f0c /system/lib64/libart.so (MterpInvokeVirtual + 592)
0x000000000054a598 /system/lib64/libart.so (ExecuteMterpImpl + 14232)
0x0000000000254148 /system/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool) (.llvm.3404100416) + 492)

但是这看起来像是系统编译的内存信息

部分场景raphael.py聚合的不准
比如

0x0000007010381000, 16785408, 1
0x00000000005932e0 /data/app/xxx/lib/arm64/libmya.so (unknown)
0x000000000045b8e4 /system/lib64/libsystem.so (unknown)
0x00000000000291c0 /data/app/xxx/lib/arm64/libmyb.so (unknown)

根据 group_record聚合函数，从栈底到栈顶遍历，只要是先找到了/data/下的so就返回，这种场景返回的是libmyb.so，实际应该返回libmya.so

def group_record(record):
    default = None
    for i in range(len(record.stack) - 1, -1, -1):
        match = re.match(r'.+\/(.+\.(so|apk|oat))', record.stack[i].path, re.M | re.I)
        if not match or match.group(1) == 'libraphael.so':
            continue
        elif record.stack[i].path.startswith('/data/'):
            return match.group(1)
        elif match.group(1) in system_group and not default:
            default = match.group(1)
    return default if default else 'extras'

使用python2.7，执行raphael.py分析report文件，报错如下，是否有python版本要求？

File "D:\open\memory-leak-detector\library\src\main\python\raphael.py", line 149, in print_report
    report.sort(lambda x, y: x.size - y.size, reverse=True)
TypeError: comparison function must return int, not long

void Raphael::start(JNIEnv *env, jobject obj, jint configs, jstring space, jstring regex) { mSpace = (char *) env->GetStringUTFChars(space, 0); 其他省略 }

mSpace 并没有释放，导致内存泄露

use libudf_unwind_backtrace(xframes, 2, STACKTRACEDEPTH) on hook _Znwj callback function the reuslt:

xHook ### allocated [12,679]K 12983343 allocCnt:2522 freeCnt:2003 by: ###00 0x00300135 _Znwj

only 1 frame! no more???

我写了一个测试程序，打debug包可以打印成完整的栈信息： 0x00000070073ba000,4100, 1 0x006000o07a4 /data/app/b~~CGuroiroinsy5nrm4podLNlkA=/com.bytedance.raphael.demo-1t7DsphtuNVaESHB3XYhr=/lib/arm64/libewjh.so ( Java_com_bytedance_demo_MemoryHookTestNative_mma) 0x0000000000222248 /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline + 152)

但是引入签名打release包，只能打印出如下栈信息： 0x0000007c16f32000, 4100, 1 0x0000000000222248 /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline + 152)

通过调试发现好像是栈回溯出现了问题。unwind_backtrace()方法在release包因为pre < fp + kFrameSize提前跳出循环。

以下是debug情况下的方法代码： 0000000000000738 <Java_com_bytedance_demo_MemoryHookTestNative_mma@@Base>: 738: d10143ff sub sp, sp, #0x50 73c: a9047bfd stp x29, x30, [sp,#64] 740: 910103fd add x29, sp, #0x40 744: d2800008 mov x8, #0x0 // #0 748: aa0803e2 mov x2, x8 74c: d2820089 mov x9, #0x1004 // #4100 750: 5280006a mov w10, #0x3 // #3 754: 52800443 mov w3, #0x22 // #34 758: 12800004 mov w4, #0xffffffff // #-1 75c: 5280008b mov w11, #0x4 // #4 760: 9000000c adrp x12, 0 __cxa_finalize@plt-0x640 764: 911f218c add x12, x12, #0x7c8 768: 9000000d adrp x13, 0 __cxa_finalize@plt-0x640 76c: 911f39ad add x13, x13, #0x7ce 770: 9000000e adrp x14, 0 __cxa_finalize@plt-0x640 774: 911f45ce add x14, x14, #0x7d1 778: f81f83a0 stur x0, [x29,#-8] 77c: f81f03a1 stur x1, [x29,#-16] 780: aa0203e0 mov x0, x2 784: aa0903e1 mov x1, x9 788: 2a0a03e2 mov w2, w10 78c: aa0803e5 mov x5, x8 790: b81e43ab stur w11, [x29,#-28] 794: f9000fec str x12, [sp,#24] 798: f9000bed str x13, [sp,#16] 79c: f90007ee str x14, [sp,#8] 7a0: 97ffffb0 bl 660 mmap@plt 7a4: f81e83a0 stur x0, [x29,#-24] 7a8: b85e43a0 ldur w0, [x29,#-28] 7ac: f9400fe1 ldr x1, [sp,#24] 7b0: f9400be2 ldr x2, [sp,#16] 7b4: f94007e3 ldr x3, [sp,#8] 7b8: 97ffffa6 bl 650 __android_log_print@plt 7bc: a9447bfd ldp x29, x30, [sp,#64] 7c0: 910143ff add sp, sp, #0x50 7c4: d65f03c0 ret

以下是release情况下的方法代码： 00000000000006d4 <Java_com_bytedance_demo_MemoryHookTestNative_mma>: 6d4: a9bf7bfd stp x29, x30, [sp,#-16]! 6d8: 910003fd mov x29, sp 6dc: 52820081 mov w1, #0x1004 // #4100 6e0: 52800062 mov w2, #0x3 // #3 6e4: 52800443 mov w3, #0x22 // #34 6e8: 12800004 mov w4, #0xffffffff // #-1 6ec: aa1f03e0 mov x0, xzr 6f0: aa1f03e5 mov x5, xzr 6f4: 97ffffcf bl 630 mmap@plt 6f8: 90000001 adrp x1, 0 __cxa_finalize@plt-0x610 6fc: 90000002 adrp x2, 0 __cxa_finalize@plt-0x610 700: 90000003 adrp x3, 0 __cxa_finalize@plt-0x610 704: 911c7021 add x1, x1, #0x71c 708: 911c8842 add x2, x2, #0x722 70c: 911c9463 add x3, x3, #0x725 710: 52800080 mov w0, #0x4 // #4 714: a8c17bfd ldp x29, x30, [sp],#16 718: 17ffffc2 b 620 __android_log_print@plt

请问我该如何编译release包才能够获得正常的栈信息？

环境

手机：Galaxy A51 操作系统：Android 10

现象

直接运行demo最新版，启动会直接crash，下面是日志 ` 2022-09-22 17:10:13.487 1215-1215/? E/Zygote: isWhitelistProcess - Process is Whitelisted 2022-09-22 17:10:13.495 1215-1215/? E/Zygote: accessInfo : 1 2022-09-22 17:10:13.503 1215-1215/? I/ce.raphael.dem: Late-enabling -Xcheck:jni 2022-09-22 17:10:13.533 1215-1215/? E/ce.raphael.dem: Unknown bits set in runtime_flags: 0x8000 2022-09-22 17:10:13.554 1215-1215/? D/ActivityThread: setConscryptValidator 2022-09-22 17:10:13.554 1215-1215/? D/ActivityThread: setConscryptValidator - put 2022-09-22 17:10:13.734 1215-1215/com.bytedance.raphael.demo I/A64_HOOK: insns pool initialized. 2022-09-22 17:10:13.735 1215-1215/com.bytedance.raphael.demo E/RAPHAEL: invoke failed at xdl_sym 2022-09-22 17:10:13.735 1215-1215/com.bytedance.raphael.demo W/ce.raphael.dem: 0xebadde09 skipped times: 0 2022-09-22 17:10:13.736 1215-1215/com.bytedance.raphael.demo A/libc: Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x753ff6532c in tid 1215 (ce.raphael.demo), pid 1215 (ce.raphael.demo)

`