析构后访问对象属于未定义行为，gdb 本身不检测，需结合 asan 定位；asan 可报告 heap-use-after-free 或 stack-use-after-scope，并精准指出分配、析构与非法访问位置。
直接结论：析构后访问对象属于未定义行为，GDB 本身不“检测”它，但可通过 ASan + GDB 联合定位；单纯靠 GDB 断点或单步无法可靠捕获该问题。
为什么 GDB 默认抓不到析构后访问
析构函数执行完，对象的内存可能尚未被覆盖或释放（尤其栈对象），此时读写成员变量仍能“成功”返回垃圾值或旧值——GDB 不会报错，print 可能显示看似合理的内容。真正崩溃往往发生在后续：比如调用虚函数（vptr 已失效）、访问已被 delete 的堆内存、或触发 ASan 检查。
常见现象包括：
- 程序在某次看似无关的
std::vector::push_back或malloc后突然SIGABRT -
bt显示崩溃在__GI___libc_malloc或__cxa_throw，而非你怀疑的那行代码 - 同一段代码有时正常、有时 crash，且
valgrind报Invalid read of size 8
必须开启 AddressSanitizer 编译
仅靠 -g 和 GDB 无法发现析构后访问。你需要让编译器注入内存访问检查逻辑：
- 使用
g++ -g -fsanitize=address -fno-omit-frame-pointer编译（Clang 同理） - 不要加
-O2或更高优化，否则 ASan 插桩可能被绕过；-O1可接受，但-O0最稳妥 - 运行时若触发 ASan 检查失败，会直接打印详细错误，包括：
heap-use-after-free或stack-use-after-scope，并附带分配/析构/非法访问三处源码位置
示例输出片段：
=================================================================
==12345==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffd1234abcd
#0 0x401234 in User::do_something() user.cpp:42
#1 0x4011ab in main main.cpp:15
0x7ffd1234abcd is located in stack of thread T0 at offset 45 in frame
#0 0x4010cd in main main.cpp:10
This frame has 2 object(s):
[32, 40) 'u'
[48, 64) 'temp_str'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism
or swapcontext. Try using -fno-omit-frame-pointer.
在 GDB 中配合 ASan 错误现场调试
ASan 崩溃时会生成信号（通常是 SIGABRT），此时可加载 GDB 精确定位：
- 先运行：
GDB ./myapp，再执行run—— ASan 触发后自动停在崩溃点 - 用
bt full查看完整栈，重点关注 ASan 自己的调用帧（如__asan_report_load8）和你代码中的上层调用 - 用
info registers查看rdi/rsi等寄存器，常含非法地址；x/4gx $rdi可查看该地址附近内存 - 若崩溃在
std::string::~string()后访问，说明该std::string对象已被析构，但指针仍被传入其他函数
注意：step 和 next 在 ASan 插桩代码里会跳进汇编，不必深究；重点看 bt 中你自己的函数名和行号。
手动验证析构时机的技巧
当怀疑某个对象是否已被析构，又不便加 ASan（如线上 release 版本），可用以下低侵入方式辅助判断：
- 在析构函数第一行加
write(STDERR_FILENO, "Dtor A\n", 9)—— 避免std::cout依赖未初始化流 - 对关键对象添加唯一标识字段（如
int magic_ = 0xDEADBEEF），析构时设为0xBADCAFE；后续访问前检查该字段 - 在 GDB 中对析构函数下断点：
break A::~A，然后watch *(int*)this监控对象内存变化（仅限简单 POD 类型）
这类技巧不能替代 ASan，但能在无符号表或受限环境下快速交叉验证。
最易被忽略的一点：析构后访问未必立即崩溃，而是在后续某次内存管理操作中才暴露——所以看到 SIGABRT 时别只盯着崩溃行，要顺着 ASan 报出的“allocated at”和“freed at”两处源头查起。
