我有两个为linux平台外包的共享库(没有源代码，没有文档(。当这些库分别链接到程序(g++xx.cpp lib1.so或g++xx.chpp lib2.so(时，它们可以正常工作
然而，当任何c++程序同时链接到这两个共享库时，该程序不可避免地会因"双自由"错误(g++xx.cpp lib1.so lib2.so(而崩溃
即使c++程序是一个空的hello-world程序，并且与这些库无关，它仍然会崩溃。
#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和valgrind，但无法从回溯中提取有用的信息。
有没有任何方法可以隔离这两个共享库，并使它们以沙箱的方式工作？
已编辑(添加核心转储和gdb回溯(：
我刚刚将前面提到的玩具空helloword程序与两个库(平台：centos7.064bits和gcc4.8.2(链接起来：
g++ helloworld.cpp lib1.so lib2.so -o check
Valgrind：
==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的帮助，我发现了一个非常相似的场景：当程序退出时，__tcf_0出现分段错误，看起来两个库之间确实存在全局变量冲突。考虑到我没有这两个外部共享库的源文件，除了使用两个单独的进程外，还有其他方法可以解决这一冲突吗？
经过一天的搜索，我已经解决了这个问题，并在这里留言，以防将来有人遇到这个问题。
解释
这证明@RaduChivn和我的猜测是正确的：这两个共享库可能共享一个共同的全局变量。即使一个空程序同时链接到两个共享库，当它退出时，公共全局变量也会被尝试释放两次，从而避免双重损坏。
线索来自gdb回溯中的这条消息：
#4 0x00007ffff7414aa2 in __tcf_0 () from ./lib1.so
如本线程所述：
什么是函数__tcf_0？(使用gprof和g++时可见(，
tcf_0是g++生成的函数，用于在触发exit((时销毁静态对象。此消息提示，当一个共享库在另一个库之后尝试退出时，会出现双重空闲。
由于这两个库是为了协同工作而设计的，因此腐败是一场不可接受的工程师灾难。这样一个低质量但明显的bug怎么能在五个版本中存活下来？这可能是由于大多数库用户在windows平台上工作(其软件包运行良好(。然而，这一假设为错误的起源提供了另一个提示：共享库在windows上运行良好，而在linux上崩溃；那么一定是某种依赖于操作系统的行为差异导致了错误。这个线程提供了一些见解：
当在exec和共享libaray中编译时，全局变量在Windows上有多个副本，在Linux上有一个副本。
简而言之；外部全局"；共享库在linux上获得单个副本，但在windows上获得多个副本。
解决方案
(1( 当然，我们会有一个变通方法，创建两个进程，每个进程分别链接到一个库。
(2( @DavidSchwartz提供了另一种变通方法，即在程序结束时使用_exit(0(，而不是常见的"0"；返回0"；或"；退出(0("；，它是有效的。根据
使用_exit((&exit((？
，必须手动刷新文件并检查atexit作业；对于内存方面，由于程序正在退出，操作系统无论如何都会回收所有进程内存，无需担心。
(3( 另一种方法是使用dlopen(xx.so，RTLD_LOCAL(，先屏蔽所有符号，然后手动dlysm需要的功能符号
(@JonathanWakely在这里指出RTLD_LOCAL有副作用，见评论(。
在这种情况下，库编码器甚至不使用"；外部C"；在他们的共享库中，使so文件中的名称混乱变得不可读；如果其他人喜欢这个，下面的线程可能会有所帮助：
动态加载共享库时出现未定义符号错误
如果您的共享库没有得到很好的支持，就像我的情况一样，解决方案仍然是可能的。我手动整理了所有需要的函数，并使用nm在.so文件中找到每个对应的符号，将它们一一链接，就成功了。
一个可能的解决方案是永远不要调用exit。要终止您的程序，只需调用_exit。如果有什么特定的事情需要做，通常由exit来完成，只需在调用_exit之前自己完成即可。