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

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

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

相关推荐
m0_736919101 小时前
C++代码风格检查工具
开发语言·c++·算法
玉梅小洋1 小时前
Windows 10 Android 构建配置指南
android·windows
2301_763472462 小时前
C++20概念(Concepts)入门指南
开发语言·c++·算法
阿猿收手吧!3 小时前
【C++】std::promise原理与实战解析
c++
Libraeking3 小时前
视觉篇:Canvas 自定义绘图与高级动画的华丽圆舞曲
android·经验分享·android jetpack
Fushize3 小时前
多模块架构下的依赖治理:如何避免 Gradle 依赖地狱
android·架构·kotlin
m0_706653233 小时前
分布式系统安全通信
开发语言·c++·算法
Zach_yuan4 小时前
深入浅出 JSONCpp
linux·服务器·网络·c++
寻寻觅觅☆4 小时前
东华OJ-基础题-104-A == B ?(C++)
开发语言·c++
Jomurphys4 小时前
Kotlin - 类型别名 typealias
android·kotlin