崩溃点在malloc/free/operator new内可断定堆破坏；若见malloc_consolidate或_int_malloc，说明堆元数据（size/fd/bk）已被篡改，需用MALLOC_CHECK_=2、gdb、SIGUSR1及ASan协同定位源头。
直接看崩溃点是否落在 malloc、free 或 operator new 内部——如果是，基本可以断定是堆被破坏了，而不是单纯越界或空指针。
崩溃栈里出现 malloc_consolidate 或 _int_malloc 怎么办
这说明 glibc 的堆管理器在整理空闲 chunk 时发现了结构异常（比如 size 字段被改写、fd/bk 指针乱码），不是你的代码主动调用出错，而是之前某次写操作悄悄踩坏了元数据。
- 立刻用
gdb ./a.out core加载 core，执行bt full，重点看最顶层是不是__libc_malloc或malloc_consolidate - 运行前加环境变量
MALLOC_CHECK_=2，它会让 malloc 在检测到损坏时立即 abort，并打印出错位置（比如 “double free or corruption (!prev)”），比静默崩溃好定位得多 - 别急着关 tcache：glibc 2.26+ 默认开启线程局部
tcache，它会缓存小块内存，掩盖真实的越界——临时用MALLOC_TRIM_THRESHOLD_=0关掉 tcache，看崩溃是否提前暴露
怎么确认是多线程导致的堆破坏而非单线程 bug
堆破坏本身不区分线程，但多线程会让破坏时机和暴露路径变得随机。关键看崩溃是否总发生在特定 arena，或是否伴随锁争抢迹象。
- 用
cat /proc/$(pid)/maps | grep heap查看进程有几个heap区域：线程数多但 heap 段只有 1–2 个，说明MALLOC_ARENA_MAX被设得太低，所有线程挤在一个 arena 里竞争，越界更容易撞上元数据 - 崩溃时用
info threads和thread apply all bt看其他线程是否卡在__lll_lock_wait+malloc，这是 arena 锁瓶颈叠加碎片的典型信号 - 发送
SIGUSR1给进程：kill -USR1 $(pidof your_program)，glibc 会把当前各 arena 的nr_free（空闲 chunk 数）和size（总空闲字节）输出到 stderr；若nr_free很大但size很小，就是大量小碎片，越界写更容易落在相邻 chunk 的 header 上
ASan 能不能抓到堆破坏？怎么用才有效
能，但要分清场景：AddressSanitizer 主要抓访问违规（越界、use-after-free），对纯粹的元数据篡改（如改写了 malloc chunk 的 size 字段）无能为力——那是 malloc 自己校验的事。不过它能帮你找到源头。
立即学习“C++免费学习笔记（深入）”；
- 编译必须加
-fsanitize=address -fno-omit-frame-pointer -g -O0：缺-fno-omit-frame-pointer会导致 ASan 报告的堆栈无法映射回源码行 - 如果 ASan 报的是
heap-buffer-overflow或heap-use-after-free，顺着它的分配/释放堆栈往上查，大概率就是破坏堆元数据的那一次越界写 - 若 ASan 完全不报错，但程序仍随机崩在
malloc里，那就得切回MALLOC_CHECK_=2+gdb，因为问题可能出在 ASan 不监控的区域（比如直接用sbrk、mmap分配的内存，或踩了 tcache 的内部结构）
堆破坏最难的点在于：你看到的崩溃点，往往离真正出问题的代码差十几轮分配/释放。不要盯着 free() 那一行修，要顺着 ASan 的“allocated by”堆栈，或 MALLOC_CHECK_=2 的 abort 位置，往更早的写操作里挖——尤其是跨线程共享的 buffer、未加锁的计数器、裸指针传递的生命周期管理。这些地方，一行没加锁的赋值，就足够让整个堆在几秒后无声崩塌。
