虚函数调用崩溃主因是对象已析构或vptr被破坏；应优先检查对象生命周期、启用AddressSanitizer/ThreadSanitizer、避免裸指针、禁用memcpy操作虚类、慎用析构中虚调用。
虚函数调用崩溃时，先确认对象是否已析构
绝大多数 virtual 函数调用崩溃（如段错误、访问违例）的根源是：对象内存已被释放，但指针仍被当作有效对象使用。C++ 不检查指针有效性，调用 vptr 时会跳转到随机地址或空地址，直接崩。
典型场景包括：返回局部对象的引用/指针、delete 后继续使用、智能指针管理不当、多线程中对象被提前销毁。
- 用 AddressSanitizer 编译运行：
g++ -fsanitize=address -g，崩溃时会明确提示heap-use-after-free或stack-use-after-scope - 在析构函数第一行加日志或断点，观察崩溃前是否已执行过该析构
- 对疑似对象的指针做简单判空无意义——野指针不等于
nullptr，if (p) p->foo()依然会崩
检查虚表指针 vptr 是否被破坏
虚函数调用依赖对象首字节处的 vptr（指向虚函数表）。若对象内存被覆写（如缓冲区溢出、未初始化内存拷贝），vptr 可能变成非法值，导致跳转失败。
调试时可在崩溃点查看对象地址的前 8 字节（64 位下）：
立即学习“C++免费学习笔记（深入）”；
gdb$ x/1gx &obj 0x7fffffffe010: 0x000055555555a020
再检查该地址是否可读、是否指向合理的虚表（比如包含类名字符串或函数地址）：
gdb$ x/4i 0x000055555555a020
- 若
vptr是0x0000000000000000或明显不属于进程地址空间（如0xdeadbeef、0xfeeefeee），大概率是未初始化或已被填充值覆盖 - 若
vptr指向只读段但内容全零，可能是对象构造未完成（例如异常中断了构造函数） - 避免用
memcpy或memset操作含虚函数的类实例——会直接抹掉vptr
用 std::shared_ptr 替代裸指针管理生命周期
裸指针无法自动反映对象生死，而 std::shared_ptr 能让崩溃更早暴露或直接避免。
关键不是“换智能指针就能修 bug”，而是利用其语义约束和调试支持：
- 把所有传入虚函数调用的参数从
Base*改成std::shared_ptr<Base>，强制调用方持有所有权 - 启用
std::shared_ptr的调试模式（GCC 下定义_GLIBCXX_DEBUG）可捕获重复释放或空解引用 - 注意循环引用：若派生类持有一个
std::shared_ptr<Base>，而Base又存了子类的shared_ptr，会导致泄漏+延迟析构——改用std::weak_ptr打破循环
多线程环境下虚函数调用崩溃要查谁在析构
单线程里对象析构顺序可控，多线程中一个线程正在调用虚函数，另一个线程可能正执行 delete 或 shared_ptr 析构，竞争条件直接导致 vptr 失效。
排查重点不在调用侧，而在销毁侧：
- 搜索所有
delete、reset()、离开作用域的shared_ptr，确认它们是否与虚函数调用共享同一对象 - 用 ThreadSanitizer：
g++ -fsanitize=thread -g，它会报告data race on vptr类似警告 - 避免在析构函数中调用虚函数（包括间接调用），因为此时动态类型已是当前类，虚函数表已切换，行为不可靠
生命周期问题不会报编译错误，也不会总在相同位置崩溃——同一段代码有时正常有时崩，往往就是对象存活边界模糊。最有效的办法不是加更多日志，而是让销毁时机变得确定：用 RAII 封装资源、用智能指针传递所有权、用 sanitizer 暴露未定义行为。一旦崩溃点稳定出现在某次析构之后，问题就基本定位清楚了。
