AddressSanitizer（ASan）是定位堆内存越界或重复释放导致“malloc(): memory corruption”的首选工具，编译时加-fsanitize=address -g即可在踩内存发生的当场报错并给出完整调用栈，支持精准定位delete栈变量、new/free混用、vector迭代器失效等场景。
用 AddressSanitizer 快速定位踩内存位置
这个错误几乎肯定是堆内存越界或重复释放导致的，malloc(): memory corruption 是 glibc 在检测到堆元数据被破坏后抛出的终局警告——此时问题早已发生，靠 gdb 断在报错点基本没用。AddressSanitizer（ASan）才是第一选择，它能在踩内存发生的**当场**报错，并给出完整调用栈。
编译时加 -fsanitize=address -g，运行直接崩在出问题那行：
g++ -fsanitize=address -g main.cpp -o main ./main
常见触发场景包括：delete 了栈变量、free 了非 malloc 分配的指针、数组下标负数或超长、std::vector::data() 缓存后继续 push_back 导致迭代器失效再访问。
注意：ASan 会显著拖慢运行速度、增大内存占用，但这是必须付出的代价；它不兼容 -O2 以上优化（建议用 -O1 或 -O0）；启用后不要同时开 valgrind，两者冲突。
立即学习“C++免费学习笔记（深入）”；
检查 malloc/free 和 new/delete 是否混用
C++ 中混用 C 风格内存管理与 C++ 风格是高危操作，malloc + delete、new + free、new[] + delete 都会导致堆元数据错乱，最终触发该错误。
典型错误模式：
-
char* p = (char*)malloc(100); delete p;→ 应该用free(p) -
int* a = new int[10]; free(a);→ 应该用delete[] a -
std::string s; char* p = &s[0]; free(p);→&s[0]不是malloc来的，不能free
如果项目里存在大量 C 接口封装，务必确认所有裸指针的生命周期和释放方式是否统一；可临时在 malloc/free/new/delete 处打日志（或用 LD_PRELOAD hook），但不如 ASan 直接。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
排查容器迭代器/指针失效后访问
STL 容器（尤其是 std::vector、std::string）扩容时会重新分配内存，原有指针、迭代器、引用全部失效。若缓存了 data()、&v[0] 或 begin()，后续又调用 push_back、resize、insert 等，再解引用就会踩内存。
示例：
std::vector<int> v = {1,2,3};
int* p = v.data(); // OK
v.push_back(4); // 可能 realloc → p 失效
printf("%d", *p); // UB，可能触发 malloc corruption解决办法：避免长期持有裸指针；必须持有时，改用索引（v[i]）或确保不触发重分配（如提前 reserve）；用 std::span（C++20）或 gsl::span 更安全。
检查多线程环境下的裸指针共享
多个线程共用一个 malloc 出来的指针，且无同步机制，极易出现 A 线程刚 free，B 线程立刻 malloc 到同一块地址并写入，破坏原堆块头信息——这种竞态不会立刻崩溃，但会在后续任意 malloc/free 时爆发为 memory corruption。
排查要点：
- 所有跨线程传递的裸指针，是否配套传递了所有权语义？
- 是否误将局部
std::vector的data()传给子线程，而主线程已析构？ - 使用
std::shared_ptr或std::unique_ptr替代裸指针，能从根本上规避生命周期错配
ASan 默认不检测数据竞争（需额外加 -fsanitize=thread），但线程问题一旦混入堆破坏，调试难度指数上升——优先用智能指针，比事后查竞态更省力。
真正棘手的是那些只在特定负载、特定内存布局下才触发的 corruption，这时候得结合 ASan 日志、core dump 和 gdb 的 info proc mappings 对照看——但 90% 的 case，打开 ASan 就已经暴露根因了。
