munmap_chunk(): invalid pointer 是野指针或重复释放错误，因 free 传入非 malloc 分配的地址，常见于栈地址释放、混用 new/delete 与 malloc/free、指针越界改写等。
为什么 munmap_chunk(): invalid pointer 不是内存泄漏而是野指针或重复释放
这个错误不是程序跑久了内存不够，而是 malloc 系统在 free 时发现传入的指针根本不在它管理的堆块头信息里——说明你释放了一个从未由 malloc/calloc/realloc 返回的地址。常见于：
释放栈变量地址、释放同一块内存两次、释放了 new 出来的对象却用 free、或者指针被意外改写（比如数组越界覆盖了指针值）。
检查 free / delete 前的指针来源是否匹配分配方式
C++ 混用 C 风格和 C++ 风格内存管理是高频雷区。系统无法容忍错配：
-
malloc分配的必须用free；new分配的必须用delete（单个对象）或delete[]（数组） - 用
new[]分配但用delete释放，或反过来，都会破坏堆元数据，触发该报错 - 如果用了
std::vector或std::string，别手动free它们的.data()——除非你明确用reserve+data()做了自定义缓冲区管理且没移交所有权
示例错误：
char* p = new char[100]; free(p); // ❌ 触发 munmap_chunk
用 AddressSanitizer 快速定位非法释放点
编译时加 -fsanitize=address -g，运行直接报出哪一行调用了非法 free 或 delete，包括调用栈和指针值：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不需要改代码，不依赖日志，比手加
printf高效得多 - 注意：ASan 会禁用部分优化，所以要关掉
-O2/-O3，用-O1或无优化编译 - 若程序依赖
LD_PRELOAD或特殊内存分配器（如 jemalloc），ASan 可能冲突，此时需临时注释相关逻辑再测
编译命令示例：
g++ -fsanitize=address -g -O1 main.cpp -o main
警惕隐式指针失效：容器操作、函数返回局部地址、智能指针误用
很多 munmap_chunk 错误源于“指针还看着合法，其实早废了”：
-
std::vector扩容后，原有迭代器/指针全部失效；若之后还拿旧指针去free，必然报错 - 函数返回局部数组首地址（如
return buf;），调用方拿到的是栈地址，free它就是非法 - 用
std::shared_ptr管理内存后，又对原始指针调用free——双重释放 - 结构体中含裸指针成员，拷贝构造/赋值未深拷贝，析构时多次释放同一块内存
这类问题不会在释放瞬间暴露，而是在后续某次 free 时因堆结构损坏才爆发，调试难度高。
真正麻烦的不是报错本身，而是它往往滞后出现——你 free 的那行代码可能完全无辜，问题出在几百行之前某个指针被悄悄覆写或提前释放了。盯住所有裸指针的生命周期，比猜报错位置更有效。
