链接到两个第三方共享库时，c ++程序崩溃
我有两个用于Linux平台的外包共享库（没有源代码，没有文档）。 当它们分别链接到程序（g ++ xx.cpp lib1.so或g ++ xx.cpp lib2.so）时，这些库工作正常。
但是，当任何c ++程序同时连接到这两个共享库时，程序不可避免地会因为“double free”错误而崩溃（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，但无法从回溯中提取有用的信息。
有没有什么办法可以隔离这两个共享库并使它们以沙盒方式工作？
EDITED（添加核心转储和gdb回溯）：
我只是将上述玩具空的helloword程序与两个库（平台：使用gcc4.8.2的centos 7.0 64bits）链接起来：
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处的段错误，看起来确实存在两个库之间的全局变量冲突。 考虑到我没有这两个外部共享库的源文件，除了使用两个单独的进程外，还有其他方法可以解决这个冲突吗？
一种可能的解决方案是永远不要exit 。 要终止你的程序，只需调用_exit 。 如果有任何特定的需要做的事情，通常会通过exit来完成，只需在调用_exit之前自行完成。
经过一天的搜索，我已经解决了这个问题，并在此留下备注，以防其他人在将来遇到此问题。
说明
它证明@RaduChivn和我的猜测是正确的：两个共享库可能共享一个通用的全局变量。 即使当一个空程序同时链接到两个共享库时，当它退出时，通用全局变量将被尝试释放两次，从而导致双重自由损坏。
线索来自gdb backtrace中的这条消息：
#4 0x00007ffff7414aa2 in __tcf_0 () from ./lib1.so
正如此线程中所述：
什么是函数__tcf_0？ （使用gprof和g ++时看到），
tcf_0是由g ++在exit（）触发时破坏静态对象的函数。 此消息提示，当一个共享库尝试在另一个共享库之后退出时发生双重空闲。
由于这两个库被设计为一起工作，腐败是一个不可接受的工程师灾难。 这样一个质量很低但很明显的错误如何能够在五个版本中生存下来？ 这可能是由于大多数在Windows平台上工作的图书馆用户（其软件包工作正常）。 然而，这个假设为错误的起源提供了另一个暗示：共享库在Windows上运行良好，而在Linux上崩溃; 那么它一定是一些操作系统相关的行为差异导致的错误。 这个线程提供了一些见解：
在exec和shared libaray中编译时，全局变量在Windows上有多个副本，在Linux上有一个。
简而言之，共享库中的“extern globals”在linux上获得单一副本，但在Windows上获得多个副本。
解
（1）当然，我们将有一种解决方法创建两个进程，每个进程分别链接到一个库。
（2）@DavidSchwartz提供了另一种在程序结束时使用_exit（0）的方法，而不是常用的“return 0”或“exit（0）”，它可以工作。 根据
传统Linux fork-exec中使用_exit（）和exit（）之间有什么区别？
，必须手动刷新文件并检查不合适的作业; 对于内存的东西，因为程序退出，操作系统无论如何回收所有的进程内存，没有什么可担心的。
（3）另一种方法是使用dlopen（xx.so，RTLD_LOCAL），首先使所有符号变暗，然后手动dlysm你需要的函数符号
（@JonathanWakely在这里指出RTLD_LOCAL有副作用，请参阅评论）。
在这种情况下，库编码器甚至没有在其共享库中使用“extern C”，从而导致名称在so文件中变得不可读; 如果其他人喜欢这一点，下面的线程可能会有所帮助：
在动态加载共享库时获取未定义的符号错误
如果你的共享库得不到很好的支持，就像我的情况一样，解决方案仍然是可能的。 我手工整理了所有需要的功能，并使用nm来查找.so文件中的每个相应的符号，将它们逐个链接起来，并且它工作正常。
链接地址: http://www.djcxy.com/p/22123.html上一篇: c++ program crashes when linked to two 3rd party shared libraries