崩溃时堆栈看不到虚函数调用链，是因为未加载调试符号；应确认二进制含debug info（Linux用file检查是否stripped，Windows用dumpbin查debug data），并排查this指针非法、对象析构后调用、内存踩坏vptr等根本原因。
崩溃时堆栈看不到虚函数调用链？先确认是否加载了调试符号
很多多线程虚函数崩溃在 GDB 或 WinDbg 里只显示 ??? 或模糊的地址，根本看不出是哪个虚函数被调了——这不是代码问题，而是调试信息缺失。没有 -g（Linux/macOS）或未启用 /Zi（MSVC），编译器不会把 vtable 符号、类名、虚函数偏移写进二进制。
实操建议：
- Linux 下用
file your_binary确认是否含 debug info；若显示 “stripped”，立刻重编译加-g -O0（避免优化干扰行号） - Windows 下检查 PDB 是否和 EXE 匹配：
dumpbin /headers your.exe | findstr "symbol"，输出应含 “debug data” - 多线程 dump 中，
bt无效时，试info registers看rdi/rcx（this 指针）是否为 0 或非法地址；再用x/20gx $rdi观察对象头前 8 字节是不是合理的 vptr 地址
崩溃点卡在 call qword ptr [rax+0x10]？这是典型的 vtable 偏移访问失败
反汇编里看到类似 call qword ptr [rax+0x10] 的指令崩了，说明程序试图通过 this 指针（rdi/rax）读取虚函数表第 2 项（偏移 0x10 = 16 字节），但 rax 指向的内存不可读，或该地址根本不是 vtable。
常见原因和排查动作：
立即学习“C++免费学习笔记（深入）”；
- 对象已被析构，但另一线程还在调它的虚函数：检查该对象生命周期是否跨线程共享，有没有用
std::shared_ptr或锁保护 - vptr 被内存踩坏：比如 buffer overflow 写到了对象头部；用 AddressSanitizer 编译（
-fsanitize=address）可直接定位越界位置 - 构造未完成就发布指针：基类构造函数里就把
this传给其他线程，此时 vptr 还指向基类 vtable，但派生类虚函数尚未就位 - 多继承下指针转换错误：比如从
Derived*强转成中间基类指针后调虚函数，偏移计算错——优先用dynamic_cast替代 C 风格转换
日志里打印 event.GetName() 崩了？别信虚函数返回值，先验 this
像 HZ_CLIENT_TRACE("{0}", event.ToString()) 这种日志宏，表面看是格式化字符串，实际可能触发 ToString() → GetName() → 虚函数调用。一旦 event 是临时对象、已 move、或内存被回收，this 就是悬空指针。
防御性写法不是加 try-catch（C++ 异常不捕获访问违规），而是提前校验：
- 在虚函数入口加断言：
assert(this != nullptr && "this is null in virtual call"); - 日志前手动检查：
if (&event == nullptr) { HZ_CLIENT_ERROR("null event in OnEvent"); return; } - 避免在日志宏里隐式调用虚函数；改用非虚的字段拼接，或把
ToString()改成非虚静态工具函数
为什么单线程不崩、一开多线程就崩？重点查三类共享状态
虚函数本身线程安全，但支撑它的对象状态往往不是。崩溃差异本质是竞态暴露了底层缺陷：
-
this指针来源是否线程安全：比如事件回调里捕获的shared_ptr<Handler>在另一线程被 reset，当前线程还拿着裸指针调虚函数 - vtable 地址被并发修改：极少见，但若类定义在 DLL 里且热重载，多个线程可能看到不同版本的 vtable
- 虚函数内部访问的成员变量没加锁：比如
GetName()返回m_name.c_str()，而m_name正被另一线程修改 —— 这时崩的不是虚调用，而是字符串 c_str() 返回的指针失效
真正难缠的不是虚函数机制本身，而是你误以为“虚函数调用”是问题根源，其实它只是第一个暴露内存错误的出口。盯住 this 指针的合法性、对象生存期的边界、以及跨线程传递方式，比研究 vtable 布局更管用。
