声明向量类型变量的段错误<shared_ptr<int>>

As you can see, -lpthread is mentioned twice! The first -lpthread (which is followed by --as-needed) is missing for the case when it gives segfault. That is the only difference between these two cases.

有趣的是，两种情况下 nm -C 的输出是相同的(如果忽略第一列中的整数值).

Interestingly, the output of nm -C in both cases is identical (if you ignore the integer values in the first columns).

0000000000402580 d _DYNAMIC
0000000000402798 d _GLOBAL_OFFSET_TABLE_
0000000000401000 t _GLOBAL__sub_I_main
0000000000401358 R _IO_stdin_used
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 w _Jv_RegisterClasses
                 U _Unwind_Resume
0000000000401150 W std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_destroy()
0000000000401170 W std::vector<std::shared_ptr<int>, std::allocator<std::shared_ptr<int> > >::~vector()
0000000000401170 W std::vector<std::shared_ptr<int>, std::allocator<std::shared_ptr<int> > >::~vector()
0000000000401250 W std::vector<std::unique_ptr<int, std::default_delete<int> >, std::allocator<std::unique_ptr<int, std::default_delete<int> > > >::~vector()
0000000000401250 W std::vector<std::unique_ptr<int, std::default_delete<int> >, std::allocator<std::unique_ptr<int, std::default_delete<int> > > >::~vector()
                 U std::ios_base::Init::Init()
                 U std::ios_base::Init::~Init()
0000000000402880 B std::cout
                 U std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
0000000000402841 b std::__ioinit
                 U std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)
                 U operator delete(void*)
                 U operator new(unsigned long)
0000000000401510 r __FRAME_END__
0000000000402818 d __JCR_END__
0000000000402818 d __JCR_LIST__
0000000000402820 d __TMC_END__
0000000000402820 d __TMC_LIST__
0000000000402838 A __bss_start
                 U __cxa_atexit
0000000000402808 D __data_start
0000000000401100 t __do_global_dtors_aux
0000000000402820 t __do_global_dtors_aux_fini_array_entry
0000000000402810 d __dso_handle
0000000000402828 t __frame_dummy_init_array_entry
                 w __gmon_start__
                 U __gxx_personality_v0
0000000000402838 t __init_array_end
0000000000402828 t __init_array_start
00000000004012b0 T __libc_csu_fini
00000000004012c0 T __libc_csu_init
                 U __libc_start_main
                 w __pthread_key_create
0000000000402838 A _edata
0000000000402990 A _end
000000000040134c T _fini
0000000000400e68 T _init
0000000000401028 T _start
0000000000401054 t call_gmon_start
0000000000402840 b completed.6661
0000000000402808 W data_start
0000000000401080 t deregister_tm_clones
0000000000401120 t frame_dummy
0000000000400f40 T main
00000000004010c0 t register_tm_clones

推荐答案

考虑到崩溃的点，而且预加载 libpthread 似乎可以修复它，我相信这两种情况的执行分歧于 locale_init.cc:315.这是代码的摘录:

Given the point of crash, and the fact that preloading libpthread seems to fix it, I believe that the execution of the two cases diverges at locale_init.cc:315. Here is an extract of the code:

  void
  locale::_S_initialize()
  {
#ifdef __GTHREADS
    if (__gthread_active_p())
      __gthread_once(&_S_once, _S_initialize_once);
#endif
    if (!_S_classic)
      _S_initialize_once();
  }

如果您的程序与 pthread 链接，

__gthread_active_p() 返回 true，特别是它检查 pthread_key_create 是否可用.在我的系统上，这个符号在/usr/include/c++/7.2.0/x86_64-pc-linux-gnu/bits/gthr-default.h"中定义为static inline，因此它是 ODR 违规的潜在来源.

__gthread_active_p() returns true if your program is linked against pthread, specifically it checks if pthread_key_create is available. On my system, this symbol is defined in "/usr/include/c++/7.2.0/x86_64-pc-linux-gnu/bits/gthr-default.h" as static inline, hence it is a potential source of ODR violation.

请注意，LD_PRELOAD=libpthread,so 将始终导致 __gthread_active_p() 返回 true.

Notice that LD_PRELOAD=libpthread,so will always cause __gthread_active_p() to return true.

__gthread_once 是另一个应始终转发到 pthread_once 的内联符号.

__gthread_once is another inlined symbol that should always forward to pthread_once.

如果不进行调试，很难猜出发生了什么，但我怀疑你正在触及 __gthread_active_p() 的真正分支，即使它不应该这样做，然后程序崩溃，因为没有pthread_once 调用.

It's hard to guess what's going on without debugging, but I suspect that you are hitting the true branch of __gthread_active_p() even when it shouldn't, and the program then crashes because there is no pthread_once to call.

编辑:所以我做了一些实验，我看到在 std::locale::_S_initialize 中崩溃的唯一方法是如果 __gthread_active_p 返回 true，但 pthread_oncecode> 没有链接进去.

EDIT: So I did some experiments, the only way I see to get a crash in std::locale::_S_initialize is if __gthread_active_p returns true, but pthread_once is not linked in.

libstdc++ 不直接链接到 pthread，但它会将 pthread_xx 的一半导入为弱对象，这意味着它们可以是未定义的并且不会导致链接器错误.

libstdc++ does not link directly against pthread, but it imports half of pthread_xx as weak objects, which means they can be undefined and not cause a linker error.

显然链接 pthread 会使崩溃消失，但如果我是对的，主要问题是您的 libstdc++ 认为它位于多线程可执行文件中，即使我们没有链接 pthread.

Obviously linking pthread will make the crash disappear, but if I am right, the main issue is that your libstdc++ thinks that it is inside a multi-threaded executable even if we did not link pthread in.

现在，__gthread_active_p 使用 __pthread_key_create 来决定我们是否有线程.这在您的可执行文件中定义为弱对象(可以是 nullptr 并且仍然可以).由于 shared_ptr (删除它并再次检查 nm 以确保)，我 99% 确定该符号存在.所以，不知何故 __pthread_key_create 被绑定到一个有效的地址，可能是因为你的链接器标志中的最后一个 -lpthread .您可以通过在 locale_init.cc:315 处设置断点并检查您采用的分支来验证这一理论.

Now, __gthread_active_p uses __pthread_key_create to decide if we have threads or no. This is defined in your executable as a weak object (can be nullptr and still be fine). I am 99% sure that the symbol is there because of shared_ptr (remove it and check nm again to be sure). So, somehow __pthread_key_create gets bound to a valid address, maybe because of that last -lpthread in your linker flags. You can verify this theory by putting a breakpoint at locale_init.cc:315 and checking which branch you take.

EDIT2:

评论摘要，只有当我们具备以下所有条件时，该问题才能重现:

Summary of the comments, the issue is only reproducible if we have all of the following:

1. 使用 ld.gold 代替 ld.bfd
2. 使用--根据需要
3. 强制 __pthread_key_create 的弱定义，在本例中通过 std::shared_ptr 的实例化.
4. 未链接到 pthread，或链接 pthread after --as-needed.

1. Use ld.gold instead of ld.bfd
2. Use --as-needed
3. Forcing a weak definition of __pthread_key_create, in this case via instantiation of std::shared_ptr.
4. Not linking to pthread, or linking pthread after --as-needed.

回答评论中的问题:

为什么默认使用黄金?

默认情况下，它使用 /usr/bin/ld，在大多数发行版中，它是指向 /usr/bin/ld.bfd 或 /的符号链接usr/bin/ld.gold.这样的默认值可以使用 update-alternatives 进行操作.我不确定为什么在你的情况下它是 ld.gold，据我了解 RHEL5 默认附带 ld.bfd.

By default it uses /usr/bin/ld, which on most distro is a symlink to either /usr/bin/ld.bfd or /usr/bin/ld.gold. Such default can be manipulated using update-alternatives. I am not sure why in your case it is ld.gold, as far as I understand RHEL5 ships with ld.bfd as default.

如果需要，gold 为什么不向二进制文件添加 pthread.so 依赖项?

And why does gold not add pthread.so dependency to the binary if it is needed?

因为对所需内容的定义有些模糊.man ld 说(强调我的):

Because the definition of what is needed is somehow shady. man ld says (emphasis mine):

--根据需要

--不需要的

此选项会影响命令行中提到的动态库的 ELF DT_NEEDED 标记在 --as-needed 选项之后.通常链接器会添加一个 DT_NEEDED命令行中提到的每个动态库的标记，无论该库是否实际需要.--as-needed 导致 DT_NEEDED 标签仅针对链接中该点满足来自常规的 非弱未定义符号 引用的库发出目标文件，或者，如果库不是在其他所需库的 DT_NEEDED 列表中找到，来自另一个所需动态的非弱未定义符号引用图书馆.目标文件或库出现在相关库之后的命令行上不会影响是否根据需要查看该库.这是相似的提取规则档案中的目标文件.--no-as-needed 恢复默认行为.

This option affects ELF DT_NEEDED tags for dynamic libraries mentioned on the command line after the --as-needed option. Normally the linker will add a DT_NEEDED tag for each dynamic library mentioned on the command line, regardless of whether the library is actually needed or not. --as-needed causes a DT_NEEDED tag to only be emitted for a library that at that point in the link satisfies a non-weak undefined symbol reference from a regular object file or, if the library is not found in the DT_NEEDED lists of other needed libraries, a non-weak undefined symbol reference from another needed dynamic library. Object files or libraries appearing on the command line after the library in question do not affect whether the library is seen as needed. This is similar to the rules for extraction of object files from archives. --no-as-needed restores the default behaviour.

现在，根据这个错误报告，gold 尊重非弱未定义符号"部分，而 ld.bfd 根据需要看到弱符号.TBH 我对此没有完全理解，关于该链接是否应被视为 ld.gold 错误或 libstdc++ 的一些讨论错误.

Now, according to this bug report, gold is honoring the "non weak undefined symbol" part, while ld.bfd sees weak symbols as needed. TBH I do not have a full understanding on this, and there is some discussion on that link as to whether this is to be considered a ld.gold bug, or a libstdc++ bug.

为什么我需要同时提到 -pthread 和 -lpthread ?(-pthread 是我们的构建系统默认通过，我已经通过 -lpthread 来制作它与黄金一起使用).

Why do I need to mention -pthread and -lpthread both? (-pthread is passed by default by our build system, and I've pass -lpthread to make it work with gold is used).

-pthread 和 -lpthread 做不同的事情(参见 pthread vs lpthread).我的理解是前者应该暗示后者.

-pthread and -lpthread do different things (see pthread vs lpthread). It is my understanding that the former should imply the latter.

无论如何，你可能只能通过一次 -lpthread，但你需要在 before --as-needed 之前这样做，或者使用--no-as-needed 在最后一个库之后和 -lpthread 之前.

Regardless, you can probably pass -lpthread only once, but you need to do it before --as-needed, or use --no-as-needed after the last library and before -lpthread.

还值得一提的是，即使使用黄金链接器，我也无法在我的系统 (GCC 7.2) 上重现此问题.所以我怀疑它已经在更新版本的 libstdc++ 中得到修复，这也可以解释为什么如果你使用系统标准库它不会出现段错误.

It is also worth mentioning that I was not able to reproduce this issue on my system (GCC 7.2), even using the gold linker. So I suspect that it has been fixed in a more recent version libstdc++, which might also explain why it does not segfault if you use the system standard library.

这篇关于声明向量类型变量的段错误<shared_ptr<int>>的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！