C++ C++；11 std:：shared_ptr工作正常，但boost:：shared_ptr崩溃，这是什么原因？

我有一个多线程程序（这里无法复制它——它有数千行），每次都可以在C++11（GCC4.7.3）上正常运行，但在使用C++03（Boost 1.53）时崩溃

具体地说，我在代码中用

boost:：atomic

和

boost:：shared_ptr

替换

std:：atomic

和

boost:：shared_ptr

（并在GCC中用

-std=c++03

编译它）。代码在其他方面是相同的

然而，C++03/Boost版本永远崩溃或循环。当它崩溃时，它会在这里崩溃：

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4dc2700 (LWP 4065)]
0x000000000043d0c8 in boost::detail::sp_counted_base::release() ()

这方面的拆解似乎是：

(gdb) disas 0x000000000043d0c8
Dump of assembler code for function _ZN5boost6detail15sp_counted_base7releaseEv:
   0x000000000043d0b0 <+ 0>:    mov    QWORD PTR [rsp-0x8],rbp
   0x000000000043d0b5 <+ 5>:    mov    ebp,0xffffffff
   0x000000000043d0ba <+10>:    mov    QWORD PTR [rsp-0x10],rbx
   0x000000000043d0bf <+15>:    mov    eax,ebp
   0x000000000043d0c1 <+17>:    sub    rsp,0x18
   0x000000000043d0c5 <+21>:    mov    rbx,rdi
=> 0x000000000043d0c8 <+24>:    lock xadd DWORD PTR [rdi+0x8],eax
   0x000000000043d0cd <+29>:    cmp    eax,0x1
   0x000000000043d0d0 <+32>:    je     0x43d0e8 <_ZN5boost6detail15sp_counted_base7releaseEv+56>
   0x000000000043d0d2 <+34>:    mov    rbx,QWORD PTR [rsp+0x8]
   0x000000000043d0d7 <+39>:    mov    rbp,QWORD PTR [rsp+0x10]
   0x000000000043d0dc <+44>:    add    rsp,0x18
   0x000000000043d0e0 <+48>:    ret    

（gdb）disas 0x000000000043d0c8
函数_ZN5boost6detail15sp_counted_base7releaseEv的汇编程序代码转储：
0x000000000043d0b0:mov QWORD PTR[rsp-0x8]，rbp
0x000000000043d0b5:mov ebp，0xffffffff
0x000000000043d0ba:mov QWORD PTR[rsp-0x10]，rbx
0x000000000043d0bf:mov eax，ebp
0x000000000043d0c1:子rsp，0x18
0x000000000043d0c5:mov rbx，rdi
=>0x000000000043d0c8:锁xadd DWORD PTR[rdi+0x8]，eax
0x000000000043d0cd:cmp eax，0x1
0x000000000043d0d0:je 0x43d0e8
0x000000000043d0d2:mov rbx，QWORD PTR[rsp+0x8]
0x000000000043d0d7:mov rbp，QWORD PTR[rsp+0x10]
0x000000000043d0dc:添加rsp，0x18
0x000000000043d0e0:ret

我看到

rdi

的值为

0x3f9dafee19598306

，该值看起来错误且未对齐（后者可能是导致崩溃的原因）

我从来没有在C++11版本上看到过任何问题（我在Windows上的Visual Studio 2013和Linux上的当前GCC上都进行过测试），但每次在C++03版本上运行它时都会出现这种情况，因此我怀疑这在我的代码中是一种竞争条件，或者我现在已经在C++11版本中看到了

所以我有点困惑-

boost:：shared_ptr

和

std:：shared_ptr

之间的什么区别可能导致这种情况

---

更新：

---

我也在使用

make_shared

。。。而且，当我避免使用

make_shared

时，C++11版本的无限循环也可以在Linux上运行（在Windows上仍然可以正常工作）。不知道这意味着什么。

我想我找到了问题所在

事实上，它不是通过

boost:：shared_ptr

实现的，而是通过我代码中的

boost:：atomic

实现的

---

boost:：atomic

不会自动归零并初始化其值

谷歌对seg故障处理功能的第一次点击是——这看起来类似吗？（它提到了代码行

if（原子交换和添加（&use\u count\u，-1）==1）

，这看起来与反汇编非常相似）@user3125280：问题看起来很相似，但似乎是因为“无效”而解决的？我不知道它有什么帮助…哎呀-还是有可能出现类似的错误，递归破坏一个大对象，导致堆栈溢出？你能在c++03代码中用make_shared vs发布代码，显示共享\u ptr构造的不同吗？@user3125280:我不能排除，我来看看。但是堆栈溢出不应该触发错误吗？代码几乎完全相同：

new_vdeps=detail:：shared_ptr（new Dependencies（））vs.
new_vdeps=detail:：make_shared（）其中
detail:：make_shared
和
detail:：shared_ptr
使用
使用std:：shared_ptr导入
detail
命名空间或
使用boost:：shared\u ptr等。两者都没有-所以这不能是两个版本之间的区别。@Casey:你确定吗？我看到
\u Atomic（）\u NOEXCEPT:\u My_val（）{/*默认构造函数*/}
“共享的\u ptr原子访问…部分[实现]”。因为它在同一个文档中说它使用boost:：share\u ptr代码，可能有问题（libstdc++程序员可能已经改变了）。@user3125280：我认为“原子访问”可能是指
std:：atomic\u xxx（shared\u ptr*，shared\u ptr）
，而不是我在使用的。@Casey：好吧，我在编写代码时没有阅读标准，我只是看着眼前的实现。