在析构函数入口设断点应使用break ~ClassName（命名空间需完整写出），而非ClassName::~ClassName；需编译时加-g且禁用返回值优化（如-O0或-fno-elide-constructors）以确保析构执行。
在析构函数入口处设断点要加 ~ClassName
析构函数名不是普通标识符，GDB 无法直接识别 ClassName::~ClassName 这种写法（尤其带命名空间时容易解析失败）。正确方式是用波浪号加类名：break ~MyClass。如果类在命名空间里，必须完整写出，比如 break ~ns::Widget；漏掉 ns:: 会导致断点设置失败但无报错，程序照常运行、断点不触发。
常见错误现象：在 gdb 里输入 break MyClass::~MyClass 或 break MyClass::dtor，GDB 显示 Function not defined 或静默忽略。这是因为 C++ 符号在调试信息中按 ABI 规则编码（如 _ZN2ns6WidgetD2Ev），GDB 的断点解析器只认 ~ClassName 这一简写形式。
使用场景：
- 想确认某个对象是否被销毁（比如怀疑 double-free 或 use-after-free）
- 验证全局/静态对象的析构顺序
- 调试
std::unique_ptr或容器析构时的资源释放逻辑
run 前得先确保编译带 -g 且没开 -fno-elide-constructors
默认开启返回值优化（RVO/NRVO）时，临时对象可能被完全省略，析构函数根本不会执行——你设了断点也永远等不到。这不是 GDB 的问题，是编译器优化行为。若需观察析构过程，应显式禁用优化或改用更可控的测试结构：
- 用
g++ -g -O0编译（最简单，适合调试阶段） - 若必须用
-O2，加-fno-elide-constructors强制调用析构（注意：这会改变程序行为，仅用于定位） - 避免依赖隐式临时对象，改用显式变量：写
MyClass obj; /* ... */而非func(MyClass());
性能影响：禁用 RVO 后，对象拷贝/移动次数上升，析构调用变多，可能掩盖真实环境下的问题。所以只在确认必要时启用。
析构顺序混乱时，backtrace 看不到调用者怎么办
全局/静态对象、atexit 回调、线程局部存储（TLS）对象的析构，往往发生在 main 返回之后，此时标准调用栈已 unwind 完毕。backtrace 可能只显示 __libc_start_main 或 exit，看不到上层上下文。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
解决办法：
- 在
gdb中先break __libc_start_main，run后用info functions .*dtor.*列出所有已知析构函数符号 - 对目标析构函数设断点后，用
set follow-fork-mode child（如有 fork）并catch syscall exit_group捕获进程退出前的最后时刻 - 更可靠的是：用
LD_DEBUG=bindings,libs配合日志，确认哪些全局对象实际参与了初始化/析构流程
容易踩的坑：在 main 结束后下断点，却忘了 GDB 默认不跟踪 exit 后的清理阶段——必须手动 catch syscall 或用 handle SIGUSR2 stop（若程序自己发信号）来卡住最后窗口。
手动调用析构函数后，print 还能看成员？别信
有人试过 call obj.~MyClass() 再 print obj.member，发现值还在，就以为“析构没生效”。这是错觉：析构函数只负责清理逻辑（如 delete ptr），不擦除内存内容。后续访问属于未定义行为（UB），GDB 可能读到旧值，也可能读到垃圾值或触发段错误。
关键判断点：
- 检查析构函数内部是否真做了资源释放（如
free、close、delete） - 用
info proc mappings和x/10xg &obj对比调用前后内存状态（需关 ASan） - 真正安全的做法是：不要手动调用析构，除非用 placement new 构造的对象——那是唯一合法场景
复杂点在于：C++ 标准允许编译器在析构后重用该内存，而 GDB 无法区分“刚析构”和“已重分配”，所以任何 print 结果都不具备可靠性。盯住源码里的 delete 和 close 调用，比看内存值更有效。
