valgrind memcheck 将析构遗漏导致的资源未释放归为 definitely lost 或 indirectly lost 泄漏，因指针随对象销毁而丢失；需用 --leak-check=full --show-leak-kinds=all -g -o0 编译并关注析构函数调用栈定位源头。
Valgrind Memcheck 会把析构遗漏当内存泄漏报出来
析构函数没释放资源（比如 new 出来的指针、malloc 的内存），Memcheck 不会单独标“析构错误”，而是归为 definitely lost 或 indirectly lost 内存泄漏——因为那块内存的指针在对象销毁后彻底丢失了，再也没人能 delete 它。
典型场景：类里用 int* a = new int[100] 分配，但析构函数里漏写 delete[] a；或者 std::vector<char> v</char> 存了裸指针却没在析构时遍历 delete。
-
valgrind --leak-check=full --show-leak-kinds=all ./myapp是必须加的，否则只告诉你“有泄漏”，不给调用栈 - 重点看报告里
at 0x...: MyClass::~MyClass (myclass.cpp:42)这一行——如果析构函数末尾没清理动作，而分配发生在构造或某个成员函数里，这里就是泄漏源头 - 如果类里有多个动态成员，
--track-origins=yes能帮你确认哪次new没被配对释放（尤其当指针被赋值多次后）
shared_ptr 循环引用不会被 Memcheck 当作泄漏，但会漏掉真正问题
shared_ptr 自身不泄漏，但它维持的循环引用会让对象生命周期异常延长，导致本该析构的对象一直活着，其内部持有的裸资源（比如文件句柄、大块缓存）无法释放。Memcheck 看不到这层语义，只会说“still reachable”——它觉得指针还被某个全局或栈上变量拿着，不是泄漏。
这种情况下，你得结合代码逻辑判断：如果一个对象理论上应该在某处销毁，但 Valgrind 报告里它持有的内存始终是 still reachable，且调用栈指向 shared_ptr 控制块，大概率是循环引用卡住了析构链。
- 别依赖
still reachable判断是否安全；它只是 OS 退出前还能访问到的内存，不代表程序逻辑正确 - 用
std::weak_ptr打断循环，或手动在关键点调用.reset()主动解引用 - 如果必须查
shared_ptr生命周期，Massif工具比Memcheck更合适（valgrind --tool=massif ./myapp）
编译时没加 -g，Valgrind 只能显示汇编地址，没法定位析构函数
没有调试信息，Valgrind 输出类似 at 0x400567: ??? (in /path/to/myapp)，你根本不知道这个地址对应哪个析构函数哪一行。它甚至可能把多个内联析构混在一起，误判成一次分配泄漏。
- 务必用
g++ -g -O0编译（-O0避免优化删掉析构调用，-g带源码映射） - 如果项目必须开优化，至少保留
-g，并避免过度内联：加-fno-inline或对关键类加__attribute__((noinline)) - 检查输出里有没有
???或in ???:???，有就说明符号缺失，重编译
第三方库的析构行为会让 Memcheck 报告变混乱
Qt、Boost 等库内部大量使用静态对象、延迟析构或自定义内存池，Valgrind 可能报出一堆 still reachable 或 Conditional jump depends on uninitialised value，但根源不在你的析构函数，而在库初始化/清理顺序里。
- 先跑一个空
main()+ 库头文件，看 Valgrind 是否仍有大量still reachable—— 如果有，说明是库自带的“噪音” - 用
--suppressions=/usr/lib/valgrind/default.supp过滤已知误报（路径按实际安装位置调整） - 真正要盯的是你自己写的类的析构函数调用栈里出现的
definitely lost，其他先搁置
Valgrind 不会告诉你“析构函数写错了”，它只忠实地反映内存去哪了。能不能看出问题，取决于你能不能从 definitely lost 的分配点，逆着调用栈找到那个没干活的析构函数——而这一步，最常卡在编译选项、第三方库干扰和 shared_ptr 语义盲区上。
