mssanitizer: 典型案例与 FAQ 排雷手册

系列四 · 第 15 篇

这是本系列的最后一篇，不展开新原理了，把前面散落的实战要点和几个高频坑收拢成一份速查，方便你上手后少走弯路。

先说检测顺序。官方建议的姿势是：先 memcheck 查内存，再 racecheck 查竞争，接着 initcheck 查未初始化，最后 synccheck 查同步。这个顺序有它的道理——内存问题最基础也最常见，先扫清底层雷，再上更耗时、更依赖时序的检测，免得被噪音干扰。

几个典型场景的用法也归纳一下。查 CANN 软件栈自己有没有内存泄漏，用"三级定界法"：先开 --check-device-heap 判断是不是 Host 侧泄的，再开 --check-cann-heap 判断是不是 ACL 接口泄的，最后引入 sanitizer 头文件重新编译，才能把"泄漏"精确到具体某一行分配代码。查 PyTorch 场景的越界，记得先 export PYTORCH_NO_NPU_MEMORY_CACHING=1 关掉内存池，否则张量复用的缓存会制造一堆假警报。

然后是几个排雷要点。

第一个坑：报告里程序位置显示 <unknown>:0，或者行号是 0。前者基本是没加 -g 编译，或者 cann-heap 场景没引入 sanitizer 头文件重编；后者多半是 -O2/-O3 优化把调试信息搅乱了，换 -O0 再跑一遍。定位不准的时候，先别怀疑工具，先查编译选项。

第二个坑：报 “records undetected” 或相关提示。这通常是记录缓冲满了，按提示把 --cache-size 调大再跑。工具给每个核预留的记录缓存默认 100MB，大算子、事件密集的算子可能会不够塞。

第三个坑：链接时报 “InputSection too large for range extension thunk”。这是链接段过大，跟检测无关，补一组针对 AICore 的链接参数（-mcmodel=large 那套）就能绕过去。

最后说一点心得式的总结。这一路十五篇下来，msSanitizer 最打动我的，其实不是它查出了多少种 bug，而是它把"影子内存"“向量时钟”"动态插桩"这些原本散落在论文和底层工具链里的硬功夫，攒成了一件普通算子开发者也能顺手一用的东西——你不需要懂那堆原理，也能在十分钟里让一个隐蔽的越界现出原形；而当你愿意深究，它背后又是一片足够好玩的技术腹地。

工具会了，去把那些"十次里偶尔错一两次"的顽固 bug 翻出来吧。