c++oding="utf-8" ?>
在libstdc++中可通过print sp._m_refcount._m_pi获取控制块地址，强引用计数位于该地址+8处，弱引用计数位于地址+0处；libc++因虚继承结构偏移不固定，推荐用gdb python脚本调用__get_use_count()或结合调试符号分析。
gdb里直接读不到C++智能指针的引用计数
因为引用计数不是公开成员，也不在对象内存布局的固定偏移上——std::shared_ptr 本身只存一个控制块指针（_M_ptr 和 _M_refcount._M_pi），真正的引用计数藏在堆上的控制块里，且不同标准库实现（libstdc++、libc++）布局完全不同。
你用 print *(int*)0x7ffff... 硬读内存，大概率读错位置或触发未定义行为。
libstdc++ 下怎么安全查 shared_ptr 的引用计数
GNU libstdc++ 的 __shared_count 控制块结构相对稳定（以 GCC 11+ 为例）：控制块头部前 8 字节是弱引用计数，再后 8 字节是强引用计数（小端序）。但必须先拿到控制块地址。
- 用
info registers或print $rdi等确认当前shared_ptr对象的地址（比如变量名是sp） - 执行
print sp._M_refcount._M_pi—— 这会输出控制块指针，如0x55555556a2a0 - 强引用计数通常在该地址 + 8 处：
print *(long long*)(0x55555556a2a0 + 8) - 弱引用计数在地址 + 0 处：
print *(long long*)(0x55555556a2a0)
注意：这个偏移对 std::shared_ptr<t></t> 成立，但若 T 是数组（shared_ptr<t></t>）或自定义删除器，控制块结构可能不同。
libc++（Clang 默认）下引用计数位置更难猜
libc++ 把控制块设计为虚继承结构，引用计数字段不保证固定偏移。硬算地址极易出错。推荐改用 GDB Python 脚本辅助：
- 写个
~/.gdbinit中注册的命令，调用sp.__get_use_count()（如果 libc++ 启用了调试符号且内联未被优化掉） - 或者用
info symbol 0x7ffff...确认地址是否落在__shared_weak_count的 vtable 区域，再结合ptype class std::__shared_weak_count查字段偏移 - 更稳妥的做法：编译时加
-D_LIBCPP_DEBUG=1并保留调试信息，部分版本会暴露__use_count_成员
多线程下查看时最常踩的坑
引用计数是原子操作更新的，GDB 暂停时看到的值只是快照——它可能正被其他线程修改中。你看到的 2 可能在单步后变成 1 或 3，不代表泄漏或提前释放。
- 不要仅凭一次
print判断生命周期问题；配合watch *0x55555556a2a0+8监视强引用计数变化更有效 - 避免在
shared_ptr构造/析构函数内部打断点查——这些函数常被内联，GDB 可能停不准，控制块地址也未必已初始化或尚未销毁 - Release 模式下
_M_refcount._M_pi可能被优化掉，必须用-O0 -g编译才能可靠访问
真正棘手的是跨线程共享同一 shared_ptr 实例时，控制块地址相同，但各线程栈上的 shared_ptr 对象是独立的——查哪个实例的 _M_refcount._M_pi 都行，只要它还活着。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
