asan通过编译插桩与影子内存检查检测越界和use-after-free等错误，需配合运行时库使用，-fsanitize=address必须与-g、-fno-omit-frame-pointer联用，避免高优化等级，并注意多进程、泄漏检测及生产环境适用性限制。
用 -fsanitize=address 检测越界和 use-after-free
Clang 的 -fsanitize=address（ASan）是检测运行时内存错误最实用的手段，它能捕获数组越界、栈/堆缓冲区溢出、use-after-free、重复释放等典型问题。它不是静态分析，而是在编译时插桩 + 运行时影子内存检查，所以必须配合可执行程序一起使用。
常见误操作是只加参数不链接运行时库——ASan 依赖 libclang_rt.asan-x86_64.so（Linux）或类似动态库，若缺失会导致链接失败或运行时报 undefined symbol: __asan_init。
- 编译命令示例：
clang -O1 -g -fsanitize=address -fno-omit-frame-pointer test.c -o test -
-fno-omit-frame-pointer必须加上，否则 ASan 无法生成准确调用栈 - 不要用
-O2及以上优化：某些优化会删掉关键检查逻辑，导致漏报 - 若程序 fork() 多进程，需额外加
-shared-libasan确保子进程也能加载 ASan 运行时
-fsanitize=memory 和 -fsanitize=undefined 的分工边界
-fsanitize=memory（MSan）专用于检测未初始化内存读（UMR），比如 kmalloc 分配后直接读取、结构体字段漏初始化。但它不检测越界或释放后访问——这些归 ASan 管。MSan 要求所有代码（包括 libc）都用 MSan 编译，实际中几乎不可行，除非你控制整个工具链。
-fsanitize=undefined（UBSan）负责整数溢出、空指针解引用、严格别名违规等，和内存布局无关。它和 ASan 可共存，但注意：两者同时启用会显著拖慢执行速度（常达 5–20 倍），建议分轮次单独跑。
- UBSan 对
NULL解引用默认只 abort，加-fsanitize=null可细化控制 - ASan 默认关闭对栈缓冲区溢出的检测（开销大），如需启用，加
-fsanitize-address-use-after-scope - 内核模块不能用 ASan/MSan：它们依赖用户态 runtime 和 mmap 影子内存，KASAN 才是内核的正确选择
为什么 -fsanitize=leak 单独用效果差
-fsanitize=leak（LSan）本身不检测泄漏，它只是 ASan 的一个组件，依赖 ASan 插桩记录所有分配/释放事件。如果只写 -fsanitize=leak 而没带 address，编译器会静默忽略 LSan，运行时零报告。
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
真正启用泄漏检测的写法是：-fsanitize=address,leak，且需确保程序正常退出（非 kill -9）。LSan 在进程 exit 时扫描未释放的堆块，若主函数里有 while(1); 或 daemon 化，就永远等不到报告。
- LSan 不报告全局/静态变量持有的内存，只管
malloc/new分配的堆内存 - 若用
dlclose()卸载共享库，其中分配的内存会被 LSan 当作泄漏——这是误报，需用__lsan_ignore_object()排除 - CI 中跑 LSan，记得设环境变量
LSAN_OPTIONS=suppressions=lsan.supp管理已知噪声
生产环境慎用，调试阶段才开
ASan 增加约 2–3 倍内存开销和 2–5 倍 CPU 开销，MSan 更重。它们会改写内存布局（比如在堆块前后插入 redzone），导致一些依赖特定地址对齐或内存布局的代码（如某些加密库、自定义分配器、内联汇编）直接崩溃或行为异常。
更隐蔽的问题是：ASan 会让原本因越界偶然“没出事”的 bug 立刻暴露，反而掩盖了真实缺陷——比如某处越界写恰好落在 padding 区域，ASan 一开就 crash，但关掉后程序看似稳定，实则数据已在腐烂。
所以，别把它当质量门禁塞进 CI 主线；更适合放在 nightly build 或 PR 的专用检查 job 里，且必须搭配符号表（-g）和完整路径构建，否则报错栈全是问号。
