title: c++ program crashes when linked to two 3rd party shared libraries
body: <p>I have two outsourced shared libraries for linux platform (no source, no document). The libraries work fine when they are linked to program separately (g++ xx.cpp lib1.so,  or g++  xx.cpp lib2.so). </p>
  
  <p>However, when any c++ program is linked to these two shared libraries at the same time, the program inevitably crashes with "double free" error (g++  xx.cpp  lib1.so lib2.so). </p>
  
  <p>Even if the c++ program is an <em>empty</em> hello world program and has nothing to do with these libraries, it still crashes. </p>
  
  <pre><code>#include &lt;iostream&gt;
  using namespace std;
  int main(){
       cout&lt;&lt;"haha, I crash again. Catch me if you can"&lt;&lt;endl;
       return 0;
  }
  </code></pre>
  
  <p>Makefile:</p>
  
  <pre><code>g++ helloword.cpp lib1.so lib2.so
  </code></pre>
  
  <p>I got some clue that these lib1.so lib2.so libraries might share some common global variable and they destroy some variable twice. I have tried gdb and valgrind, but cannot extract useful information from backtrace. </p>
  
  <p>Is there any way that I could possibly isolate these two shared libraries and make them work in a <em>sandbox</em> manner?</p>
  
  <p>EDITED (adding core dump and gdb backtrace):</p>
  
  <p>I just linked the aforementioned toy empty helloword program with the two libraries (platform: centos 7.0 64bits with gcc4.8.2):</p>
  
  <pre><code>g++ helloworld.cpp  lib1.so lib2.so -o check
  </code></pre>
  
  <p>Valgrind:</p>
  
  <pre><code>==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)
  </code></pre>
  
  <p>gdb backtrace message:</p>
  
  <pre><code>(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?)
  </code></pre>
  
  <p><strong>update</strong></p>
  
  <p>Thanks for @RaduChivu 's help, I found a very similar scenario:  <a href="https://stackoverflow.com/questions/8472429/segmentation-fault-at-tcf-0-when-program-exits">segmentation fault at __tcf_0 when program exits</a> , looks like indeed there is a global variable collision between the two libraries. Considering I do not have the source files for these two external shared libraries, except for using two separate processes, is there any other way that I can resolve this conflict?</p>