addresssanitizer（asan）能快速捕获越界读写，因其采用编译期插桩与影子内存机制，在错误发生时立即崩溃并输出带源码行号的详细日志；而valgrind因动态二进制翻译导致性能开销达10–30倍，不适用于线上监控或资源受限环境。
用 AddressSanitizer 快速捕获越界读写
AddressSanitizer（ASan）是 GCC 和 Clang 内置的内存错误检测器，能实时发现数组越界、栈/堆缓冲区溢出、释放后使用等行为。它不是运行时库补丁，而是编译期插桩，因此无需修改源码，但必须重新编译。
常见错误现象：程序崩溃但 core dump 没有明显线索；valgrind 报 Invalid read of size 4 却定位不到具体行；或者只在特定数据下偶发异常。
- 启用方式：编译时加
-fsanitize=address -g，链接时也需带相同选项（Clang/GCC ≥ 4.8） - 必须保留
-g，否则报错只显示汇编地址，无法映射到源码行 - 不要和
-O2以上优化共用——部分越界可能被优化掉，ASan 插桩也会失效；建议用-O1或-O0 - 运行时报错示例：
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000001c at pc 0x000000401234 bp 0x7ffd12345678 sp 0x7ffd12345660，后面会紧跟着调用栈和越界访问的变量名、偏移量
为什么不用 valgrind 做线上越界监控
valgrind 的 memcheck 工具虽能查越界，但它基于动态二进制翻译，性能开销通常达 10–30 倍，且不支持某些系统调用（如 ptrace、perf_event_open），导致部分服务根本跑不起来。它也不适合嵌入式或资源受限环境。
更关键的是：valgrind 默认不记录首次越界发生时的完整上下文（比如触发越界的输入参数、线程 ID、时间戳），上报链路需要额外开发，而 ASan 可通过环境变量直接导出符号化报告。
- 用
ASAN_OPTIONS=abort_on_error=1:handle_abort=1让进程在首次越界时立刻abort()，便于抓core - 用
ASAN_OPTIONS=log_path=/tmp/asan.log将所有越界事件追加写入文件，适合无人值守场景 - 注意：ASan 日志默认不包含线程名或自定义 tag，如需关联业务上下文，得在触发越界前手动打日志（例如
LOG(INFO) ）
Release 模式下如何保留基础越界防护
ASan 不能上生产——体积膨胀约 2×，内存占用高，且关闭优化后性能不可接受。但完全放弃防护也不现实。折中方案是启用编译器内置的轻量级检查：GCC 的 -D_FORTIFY_SOURCE=2 和 Clang 的 -fstack-protector-strong。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
它们不检测任意指针算术越界，但对常见 C 标准库函数（如 memcpy、strcpy、printf）做长度校验，一旦发现目标缓冲区太小就触发 __stack_chk_fail 并终止进程。
- 必须配合
-O2使用，否则大部分检查会被优化掉 - 仅对静态可知大小的数组有效；对
malloc返回的指针无效 - 错误信息极简：
*** stack smashing detected ***: terminated，无调用栈——需搭配libbacktrace或abrt机制补充 - 别依赖它替代 ASan：它漏检率高，比如
arr[i] = x;这种裸数组访问完全不检查
自定义 malloc hook 不适合越界追踪
有人想用 __malloc_hook / malloc_usable_size + 地址范围比对实现“手动 ASan”，这在技术上可行但实际不可靠。
问题在于：C++ 中越界常发生在非 malloc 分配的内存上——栈变量、全局数组、mmap 映射区、对象成员变量，这些区域 malloc_usable_size 根本不识别；而且 hook 本身有性能损耗，多线程下还需锁保护，容易引入死锁或掩盖原有 bug。
- Hook 无法拦截
operator new[]之外的分配（比如alloca、std::array） - 即使拦截了
new，也无法得知后续下标是否越界——你只能知道“分配了 N 字节”，但不知道代码里写了p[100] - 现代 libc（如 glibc 2.34+）已废弃
__malloc_hook，改用malloc_hooks接口，兼容性差
真正需要线上自动上报的场景，应优先考虑编译期注入（如 ASan 编译测试包）、或用 eBPF 在内核层捕获用户态非法访存（如 uretprobes 监控 __asan_report_load4 等符号），但后者要求 kernel ≥ 4.18 且需 root 权限。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
