保留原始结论,并把零散备注整理成便于回看的排查清单。
基本链接方式
使用 ASan 时,链接参数里需要带上线程库和 ASan 库,原始记录里特别提到:
-pthread -lasan
-pthread 建议放在前面,避免某些环境里链接顺序导致的问题。
LeakSanitizer
Linux 或虚拟机环境通常可以直接查 leak;
WSL 下泄漏结果不一定稳定,可能看不到预期输出。
因此如果主要目的是确认内存泄漏,优先在原生 Linux 环境复现。
AddressSanitizer
WSL 更适合查 use-after-free、越界访问这类地址问题。
也就是说:
- 查地址非法访问:WSL 可以先快速验证
- 查内存泄漏:更建议回到原生 Linux
Android ASan
原始记录里的结论是:
32 位 Android 13 及以前,通常需要配合专门的 ROM 或调试环境;
部分机型本身就不再提供 32 位支持,需要先确认设备能力。
整理后建议先确认三件事:
- 目标进程是 32 位还是 64 位
- 设备系统是否允许加载对应的 sanitizer 运行时
- ROM / root / 调试权限是否满足注入要求
Android HWASan
原始备注:
64 位 Android 14 及以后更适合走 HWASan;
某些场景不需要 `wrap.sh`,强行带上反而可能导致编译或启动失败。
因此实际排查时不要默认照搬旧资料里的 wrap.sh 配置,先以当前 NDK、ROM 和构建链路验证为准。
建议的使用顺序
如果只是想尽快定位问题,可以按下面顺序尝试:
- Linux / WSL 先复现基础内存问题
- Linux 环境确认 leak
- Android 侧再区分 ASan 还是 HWASan
- 最后再补设备、ROM、ABI 兼容性验证
FEATURED TAGS
Git
Cheat Sheet
Markdown
Tools
C++
Linker
Thread
Linux
TCP
Network
GDB
Debug
leetcode
链表
WSL
Ubuntu
Windows
Linux Kernel
GCC
Android
adb
Troubleshooting
Profiling
Sanitizer
glibc
MySQL
Database
Python
curl
Build
ELF
clang-format
CMake
Graphviz
Performance
vcpkg
Protobuf
排查
速查
内存
STL
调试
性能分析
性能
读书笔记
方法论
架构
网络
Timer
mbedTLS
TLS
安全
负载均衡
脚本
工具
LRU
二叉树
BST
中序遍历
回溯
二分查找
优先队列
排序
旋转数组
jenkins
部署