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

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

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

相关推荐
zh_xuan1 小时前
Android 传统view嵌入compose
android
ZHANG13HAO3 小时前
Android 13 AOSP 内置 NekoTTS 中文免费商用 TTS 完整流程
android
老四啊laosi7 小时前
[C++进阶] 24. 哈希表封装unordered_map && unordered_set
c++·哈希表·封装·unordered_map·unordered_set
许杰小刀8 小时前
ctfshow-web文件包含(web78-web86)
android·前端·android studio
妙为8 小时前
银河麒麟V4下编译Qt5.12.12源码
c++·qt·国产化·osg3.6.5·osgearth3.2·银河麒麟v4
weixin_446023569 小时前
C语言:面向过程、应用底层开发、跨平台的通用程序设计语言
c语言·跨平台·数据类型·底层开发·面向过程
无敌昊哥战神10 小时前
深入理解 C 语言:巧妙利用“0地址”手写 offsetof 宏与内存对齐机制
c语言·数据结构·算法
史迪仔011211 小时前
[QML] QML IMage图像处理
开发语言·前端·javascript·c++·qt
cmpxr_12 小时前
【C】数组名、函数名的特殊
c语言·算法