当链接到两个第三方共享库时，c++程序崩溃
我有两个用于linux平台的外包共享库(没有源代码，没有文档)。当库分别链接到程序时(g++ xx.cpp lib1.so或g++ xx.cpp lib2.so)，它们可以正常工作。
但是，当任何c++程序同时链接到这两个共享库时，程序不可避免地会出现“双空闲”错误(g++ xx.cpp lib1.so lib2.so)。
即使c++程序是一个空的hello程序，并且与这些库无关，它仍然会崩溃。
#include <iostream>
using namespace std;
int main(){
cout<<"haha, I crash again. Catch me if you can"<<endl;
return 0;
}Makefile：
g++ helloword.cpp lib1.so lib2.so我得到了一些线索，这些lib1.so lib2.so库可能共享一些通用的全局变量，并且它们会销毁一些变量两次。我曾经尝试过gdb和val差制，但无法从backtrace中提取有用的信息。
有没有可能隔离这两个共享库，并使它们以沙箱的方式工作？
编辑(添加核心转储和gdb回溯)：
我刚刚将上述玩具空helloword程序与两个库(平台:CentOS7.64bit与gcc4.8.2)链接在一起：
g++ helloworld.cpp lib1.so lib2.so -o check瓦兰：
==29953== Invalid free() / delete / delete[] / realloc()
==29953== at 0x4C29991: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==29953== by 0x613E589: __cxa_finalize (in /usr/lib64/libc-2.17.so)
==29953== by 0x549B725: ??? (in /home/fanbin/InventoryManagment/lib1.so)
==29953== by 0x5551720: ??? (in /home/fanbin/InventoryManagment/lib1.so)
==29953== by 0x613E218: __run_exit_handlers (in /usr/lib64/libc-2.17.so)
==29953== by 0x613E264: exit (in /usr/lib64/libc-2.17.so)
==29953== by 0x6126AFB: (below main) (in /usr/lib64/libc-2.17.so)
==29953== Address 0x6afb780 is 0 bytes inside a block of size 624 free'd
==29953== at 0x4C29991: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==29953== by 0x613E589: __cxa_finalize (in /usr/lib64/libc-2.17.so)
==29953== by 0x4F07AC5: ??? (in /home/fanbin/InventoryManagment/lib2.so)
==29953== by 0x5039900: ??? (in /home/fanbin/InventoryManagment/lib2.so)
==29953== by 0x613E218: __run_exit_handlers (in /usr/lib64/libc-2.17.so)
==29953== by 0x613E264: exit (in /usr/lib64/libc-2.17.so)
==29953== by 0x6126AFB: (below main) (in /usr/lib64/libc-2.17.so)gdb回溯消息：
(gdb) bt
#0 0x00007ffff677d989 in raise () from /lib64/libc.so.6
#1 0x00007ffff677f098 in abort () from /lib64/libc.so.6
#2 0x00007ffff67be197 in __libc_message () from /lib64/libc.so.6
#3 0x00007ffff67c556d in _int_free () from /lib64/libc.so.6
#4 0x00007ffff7414aa2 in __tcf_0 () from ./lib1.so
#5 0x00007ffff678158a in __cxa_finalize () from /lib64/libc.so.6
#6 0x00007ffff739f726 in __do_global_dtors_aux () from ./lib1.so
#7 0x0000000000600dc8 in __init_array_start ()
#8 0x00007fffffffe2c0 in ?? ()
#9 0x00007ffff7455721 in _fini () from ./lib1.so
#10 0x00007fffffffe2c0 in ?? ()
#11 0x00007ffff7debb98 in _dl_fini () from /lib64/ld-linux-x86-64.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)更新
谢谢@RaduChivu的帮助，我发现了一个非常类似的场景：0 when program exits，看起来两个库之间确实存在全局变量冲突。考虑到我没有这两个外部共享库的源文件，除了使用两个单独的进程之外，还有其他方法可以解决这个冲突吗？
回答 2
Stack Overflow用户
发布于 2014-08-01 08:21:28
经过一天的搜索，我已经解决了这个问题，并在这里留下了一张便条，以防其他人将来遇到这种情况。
解释
它证明了@RaduChivn (我的猜测)是正确的:两个共享库可能共享一个通用的全局变量。即使当一个空程序同时链接到两个共享库时，当它退出时，通用的全局变量也会被尝试释放两次，从而造成双重的免费损坏。
这条线索来自gdb回溯中的消息：
#4 0x00007ffff7414aa2 in __tcf_0 () from ./lib1.so如本线程所述：
0? (Seen when using gprof and g++)，
tcf_0是由g++生成的函数，用于在触发exit()时对静态对象进行析构。此消息暗示，当一个共享库试图在另一个共享库之后退出时，就会出现双空闲。
由于这两个图书馆是设计合作的，腐败是一个不可接受的工程灾难。这样一个低质量但明显的bug怎么能在五个版本中存活下来呢？这可能是因为大多数图书馆用户都在windows平台上工作(其软件包工作得很好)。然而，这一假设为错误的起源提供了另一个提示:共享库在windows上运行良好，而在linux上崩溃；然后，它必须是与操作系统相关的行为差异，从而导致了错误。这个线程提供了一些洞察力：
简而言之，共享库中的"extern globals“在linux上得到单个副本，而在windows上得到多个副本。
解决方案
(1)自然地，我们会有一个解决办法，创建两个进程，每个进程分别链接到一个库。
(2) @DavidSchwartz提供了另一种在程序结束时使用_exit(0)的解决方案，而不是普通的“返回0”或“退出(0)”，它可以工作。根据
exit() & exit() in a conventional Linux fork-exec?
，必须手动刷新文件并检查atexit作业；对于内存问题，由于程序退出，OS无论如何都会回收所有进程内存，没有什么好担心的。
(3)另一种方法是使用dlopen(xx.so，RTLD_LOCAL)，先对所有符号进行盲化，然后手动处理所需的函数符号。
(@JonathanWakely在这里指出，RTLD_LOCAL有副作用，见评论)。
在这种情况下，库编码器甚至没有在它们的共享库中使用"extern C“，这使得so文件中的名称很难读懂；如果其他人喜欢这样，下面的线程可能会有所帮助：
Getting undefined symbol error while dynamic loading of shared library
如果您的共享库得不到很好的支持，就像在我的例子中一样，解决方案仍然是可能的。我手动整理了所有需要的函数，并使用nm在.so文件中找到每个对应的符号，一个接一个地将它们链接起来，并且成功了。
Stack Overflow用户
发布于 2014-08-07 06:06:38
一个可能的解决方案是永远不调用exit。要终止您的程序，只需调用_exit。如果您需要做任何特定的事情，通常是由exit来完成的，那么在调用_exit之前自己去做。
https://stackoverflow.com/questions/25051679
复制相似问题
腾讯云开发者
