静态初始化期间的死锁

Question

我在Solaris中的静态初始化期间遇到了死锁。这种情况非常类似于this user's problem。

我的环境是：

• solaris 10
• gcc 5.4安装到非标准位置
• 所有相关的共享库都链接到该安装中的libstdc ++和/或libgcc_s库
• 提升1.45（我们很快就会离开它，但目前无法改变）
• 在动态链接或与boost库
时，我发现了这个问题

症状：

• 执行boost::system::generic_category()
时出现死锁 正在调用
• generic_category()来初始化boost/system/error_code.hpp
中的全局静态引用
• 如果我改变链接顺序，将-lboost_system置于链接的其他库之前，则问题就会消失。
• 如果我在generic_category()中设置断点，然后在第一次遇到断点后尝试跳过第1行，则在不同的共享库中执行相同的函数时，断点会再次被击中_init() - 也就是说，当我告诉它跳过第一行时，它永远不会在generic_category()的第二行停止。

由于踩过第1线并没有起作用，我走进去然后走出去了＆amp;再一次，断点被击中了。

我重新启动了这个过程＆amp;在断点被击中后介入，然后开始踩踏。单步调用boost::system::error_category::error_category()我遇到了同样的问题。

我再次尝试，这次是在我进入error_category()电话的时候踩了一条指令。它试图通过调用elf_rtbndr()的PLT来调用它，该%o0应该返回elf_rtbndr()中的实际函数地址，但当我再次调用generic_category()时击中断点而不是从中断处恢复。

当断点第二次被点击时，它会在其他一些共享库_init()中调用geography::Point();发生僵局时的那个。

提前感谢您的时间和帮助

Answer 1

已多次报告此情况（请参阅this post in Boost和another in GCC）。这似乎是Boost初始化期间的循环依赖问题，由于某种原因，它只在Solaris上出现。通常的建议是通过搞乱库初始化来解决这个问题（例如，通过像对-lboost_system那样对库顺序进行混洗）。

另一种选择是禁用线程安全防护（-fno-threadsafe-statics标志），它将摆脱死锁，但会保留错误的嵌套构造函数调用，这是不可取的。