Android应用程序 c/c++ 崩溃排查流程二——AddressSanitizer工具使用

目录

1.背景

2.ASan工具集成到应用中进行使用

3.使用ASan工具查看日志


1.背景

由于在Android应用中进行c/c++编程会有各种crash或者内存指针异常,如果内存需要查看哪地方进行释放内存是无法通过addr2line或者ndk-stack工具排查出来的,这时就需要使用AddressSanitizer对内存异常的进行深度分析,例如list收尾相连成为环形了,如下:

主要代码逻辑如下:

根本原因:Scudo(Android 11+ 的默认内存分配器)检测到要释放的内存块的头部信息(chunk header)已被破坏 。

直接触发点 :在 osa_free中释放某个内存块(地址 0xd0061100)时,Scudo 验证发现其头部校验和不匹配 。头部可能因内存越界写入 (如缓冲区溢出)或使用已释放内存(use-after-free)而损坏 。

重要背景 :在崩溃前,您的队列验证代码多次检测到并修复了循环链表("Circular list confirmed! Cycle detected after X steps")。队列结构持续被破坏,暗示存在持续的内存越界写入严重的并发访问问题​ 。

Scudo 本身是一种缓解机制,而 ASan 能更精确地定位内存错误,此处就需要用到ASan工具

2.ASan工具集成到应用中进行使用

1.在AndroidManifest.xml中添加:

复制代码
android:extractNativeLibs="true"

如下:

2.在gradle中添加

复制代码
useLegacyPackaging = true

如下是我的配置

如果不行直接把我的配置拷贝进去

复制代码
    packagingOptions {
        jniLibs {
            useLegacyPackaging = true  // 兼容旧版本Gradle
        }
        resources {
            // 包含所有.so文件
            pickFirsts += "**/*.so"
            // 包含静态库(如果需要)
            pickFirsts += "**/*.a"
        }
    }

3、将wrap.sh 文件添加到 src/main/resources/lib 目录中的对应目录。我这边是32位的,如下:

wrap.sh内容如下,直接拷贝即可:

bash 复制代码
#!/system/bin/sh
HERE="$(cd "$(dirname "$0")" && pwd)"
export ASAN_OPTIONS=log_to_syslog=false,allow_user_segv_handler=1
ASAN_LIB=$(ls $HERE/libclang_rt.asan-*-android.so)
if [ -f "$HERE/libc++_shared.so" ]; then
    # Workaround for https://github.com/android-ndk/ndk/issues/988.
    export LD_PRELOAD="$ASAN_LIB $HERE/libc++_shared.so"
else
    export LD_PRELOAD="$ASAN_LIB"
fi
"$@"

也可以参考:https://developer.android.com/ndk/guides/asan?hl=zh-cn#ndk-build

4.找到asan的动态库,和其他动态库一样集成到项目中

首先我这边是用的32位库,路径如下:

Sdk\ndk\23.1.7779620\toolchains\llvm\prebuilt\windows-x86_64\lib64\clang\12.0.8\lib\linux

然后集成到项目中,这里的流程就是和一般的so包一样进行集成即可

上述的流程就完成了ASan工具的集成

3.使用ASan工具查看日志

上述集成完成,然后我们运行应用,如果有wrap.sh相关的AddressSanitizer打印说明我们集成成功了,如下:

从ASan报告中有几个关键信息点:

  1. 错误类型AddressSanitizer: attempting free on address which was not malloc()-edSUMMARY: AddressSanitizer: bad-free。这直接指明了是无效的释放操作。

  2. 地址位置Address 0xc99ce0f8 is located in stack of thread T20 (Thread-4)。这是最关键的线索 ,它表明您的程序试图释放(free)的内存地址是一个位于**线程栈(stack)**上的局部变量,而栈内存是由系统自动管理(函数返回时自动回收)的,绝不能手动释放。

  3. 调用栈 :调用栈显示了从 liblpa.so开始的函数调用链,错误就发生在这个库中。您需要沿着这个调用栈来定位问题代码。

然后我们使用addr2line工具进一步定位,不会用addr2line工具的可以看前一篇文章:

https://blog.csdn.net/gongjdde/article/details/155744018?sharetype=blogdetail&sharerId=155744018&sharerefer=PC&sharesource=gongjdde&spm=1011.2480.3001.8118

此时我们就定位到错误的位置了,如下:

可以看出来这个是局部的变量,不能被回收,所以导致出现无效的释放,将这行代码删除即可

相关推荐
Android-Flutter21 小时前
android compose DropdownMenu 菜单项列表 使用
android
qq_4017004121 小时前
QT C++ 好看的连击动画组件
开发语言·c++·qt
额呃呃1 天前
STL内存分配器
开发语言·c++
七点半7701 天前
c++基本内容
开发语言·c++·算法
嵌入式进阶行者1 天前
【算法】基于滑动窗口的区间问题求解算法与实例:华为OD机考双机位A卷 - 最长的顺子
开发语言·c++·算法
嵌入式进阶行者1 天前
【算法】用三种解法解决字符串替换问题的实例:华为OD机考双机位A卷 - 密码解密
c++·算法·华为od
青莲8431 天前
Java内存模型(JMM)与JVM内存区域完整详解
android·前端·面试
林栩link1 天前
【车载Android】「场景引擎」设计思路分享
android
啊董dong1 天前
noi-2026年1月07号作业
数据结构·c++·算法·noi