“pure virtual method called”本质是虚表指针（vptr）被破坏，而非真调用纯虚函数；gdb调用栈常因帧指针或返回地址损坏而不可信，需优先验证对象存活性、检查多线程竞争、vptr非法值及前置内存越界。
崩溃现场只显示“pure virtual method called”但调用栈不可信
这通常不是真的调用了纯虚函数，而是虚函数表（vtable）已被破坏，导致对象的 vptr 指向了非法内存或被覆盖的垃圾数据。GDB 中看到的调用栈常是错乱的，因为返回地址或帧指针本身可能已损坏。不要急于在栈顶函数里找逻辑错误——先确认对象是否还“活着”。
实操建议：
- 立即检查崩溃前最近一次对该对象的写操作：是否有多线程同时修改该对象？尤其注意非原子的成员赋值、
memcpy整块拷贝、或裸指针越界写入 - 用
info registers查看rax/rdi（this 指针）和rip（跳转目标），对比该对象原始地址与vptr值：x/1gx &obj→ 若结果是明显非法地址（如0xdeadbeef、0x00000000或接近栈底/堆顶的极端值），基本坐实 vtable 被覆写 - 关闭编译器优化（
-O0）并启用-fno-omit-frame-pointer，否则栈回溯会进一步失真
如何用 AddressSanitizer 捕获 vtable 破坏的源头
ASan 默认不检测虚表区域，但它能捕获导致虚表损坏的**前置越界写**。关键在于让 ASan 看到虚表所在内存页的布局——这要求对象必须分配在堆上（new），且不能被编译器内联掉构造过程。
实操建议：
- 确保触发崩溃的代码路径中，对象通过
new分配（而非栈对象或静态对象），例如：auto p = new Derived();而非Derived d; - 编译时加
-fsanitize=address -fno-omit-frame-pointer -g，运行后若崩溃由越界写引发，ASan 会直接报出类似heap-buffer-overflow on address 0x602000000028 at pc 0x000000401234的精确位置 - 若 ASan 无输出，说明破坏发生在 ASan 无法监控的区域（如栈上对象的虚表、或通过
mmap手动管理的内存），此时需转向硬件断点或valgrind --tool=memcheck
多线程竞争下 vtable 被覆写的典型模式
vtable 本身是只读段（.rodata）中的常量数据，不可能被直接改写；真正被破坏的是对象头部的 vptr 字段。而这个 8 字节（x64）字段极易成为竞态写入的目标。
常见错误场景：
- 两个线程同时对同一对象调用不同生命周期操作：线程 A 正在执行
delete p，线程 B 却还在调用p->foo()—— 此时vptr可能刚被析构函数清零或覆写为垃圾值 - 使用
std::shared_ptr但未用std::atomic保护裸指针传递：例如把shared_ptr<base>::get()返回的裸指针传给另一线程，而原线程随时可能释放资源 - 自定义内存池中未对齐分配：若对象起始地址未按平台对齐（如 x64 下非 8 字节对齐），某些编译器生成的虚表加载指令可能触发未定义行为，间接污染邻近内存
用 GDB 硬件观察点锁定 vptr 修改位置
当常规日志和 ASan 都失效时，唯一可靠的方式是监控 vptr 内存地址本身是否被意外写入。这需要硬件支持的观察点（hardware watchpoint），比普通断点更精准。
实操步骤：
- 在 GDB 中先定位对象地址：
p &obj，再读取其虚表指针：x/1gx &obj（假设vptr在对象起始处） - 设置写入观察点：
watch *(void**)(&obj)—— 注意必须用void**强制解释为指针地址，否则 GDB 可能拒绝设置 - 运行程序：
r，GDB 将在任何线程写入该地址时中断，并显示确切的汇编指令和调用栈 - 注意：硬件观察点数量有限（通常 4 个），避免同时设多个；且仅对全局/堆对象有效，栈对象因地址频繁变化难以稳定监控
vtable 损坏本质是内存安全问题的晚期症状，它从不单独发生。真正要盯紧的，永远是那个在多线程间裸奔的指针、那块没加锁就共享的对象内存、以及所有绕过 RAII 直接操作 raw pointer 的地方。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
