如何排查C++中pure virtual method called错误？相关问题求助

一、为什么抽象类不能实例化却出现该错误？ #

这个错误不是因为实例化了抽象类，而是以下几种场景导致：

• 调用了已销毁对象的虚函数：对象析构后，其虚表可能被重置为基类的虚表（其中纯虚函数的条目是占位符），此时通过残留的指针/引用调用虚函数，就会触发该错误。
• 基类构造/析构函数中调用纯虚函数：基类构造时，派生类还未完成构造，虚函数的调用会绑定到基类的版本；基类析构时，派生类已经析构，虚表退回到基类状态。如果此时调用纯虚函数，直接触发错误。
• 进程间非法传递对象指针：父子进程地址空间独立，父进程的对象指针在子进程中是无效地址，若子进程误将其当作有效对象调用虚函数，可能触发该错误。

二、错误排查方案（适配父子进程+高负载场景） #

1. 先定位错误发生的进程 #

• 在父、子进程启动时，打印各自的进程ID（getpid()），同时在关键位置（比如虚函数入口、对象析构函数）添加日志，标注进程ID和对象地址，便于关联错误发生的进程。
• 将父、子进程的标准错误输出分别重定向到不同文件（比如启动子进程时用freopen("child_stderr.log", "w", stderr)），分开排查日志。

2. 替代Valgrind的高效工具 #

• AddressSanitizer (ASAN)：编译时添加参数-fsanitize=address -g，运行时会快速检测内存非法访问（包括访问已销毁对象），直接定位到错误代码行。默认会跟踪子进程，能捕获子进程的内存问题，性能开销远低于Valgrind。
• UndefinedBehaviorSanitizer (UBSAN)：配合ASAN使用，添加编译参数-fsanitize=undefined，专门检测未定义行为，包括调用纯虚函数的场景，能给出精准的错误提示。
• Core Dump分析：提前执行ulimit -c unlimited开启core dump，错误发生后生成core文件。用GDB加载：gdb ./your_encoder core，执行bt查看调用栈，直接定位错误发生的调用链。子进程崩溃也会生成独立的core文件，可通过进程ID区分。

3. 代码层面的排查要点 #

• 检查所有纯虚函数的调用点：确保调用时对象处于存活状态，尤其注意异步任务、多线程回调中是否持有了已销毁对象的指针/引用。
• 禁止在基类构造/析构函数中调用纯虚函数：这是C++中的明确禁忌，会直接触发未定义行为。
• 排查进程间通信逻辑：父子进程不能直接传递对象指针，若需共享对象，需用序列化、共享内存等正确方式，避免无效地址访问。
• 检查智能指针使用：若使用裸指针，确保没有提前释放；若用std::shared_ptr/std::weak_ptr，排查是否存在循环引用导致对象提前销毁，或误用了weak_ptr的过期对象。

内容的提问来源于stack exchange，提问作者Jacko