title: segfault during __cxa_allocate_exception in SWIG wrapped library
body: <p>While developing a SWIG wrapped C++ library for Ruby, we came across an unexplained crash during exception handling inside the C++ code.</p>
  
  <p>I'm not sure of the specific circumstances to recreate the issue, but it happened first during a call to <code>std::uncaught_exception</code>, then after a some code changes, moved to <code>__cxa_allocate_exception</code> during exception construction. Neither GDB nor valgrind provided any insight into the cause of the crash.</p>
  
  <p>I've found several references to similar problems, including:</p>
  
  <ul>
  <li><a href="http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception" rel="noreferrer">http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception</a></li>
  <li><a href="http://forums.fifengine.de/index.php?topic=30.0" rel="noreferrer">http://forums.fifengine.de/index.php?topic=30.0</a></li>
  <li><a href="http://code.google.com/p/osgswig/issues/detail?id=17" rel="noreferrer">http://code.google.com/p/osgswig/issues/detail?id=17</a></li>
  <li><a href="https://bugs.launchpad.net/ubuntu/+source/libavg/+bug/241808" rel="noreferrer">https://bugs.launchpad.net/ubuntu/+source/libavg/+bug/241808</a></li>
  </ul>
  
  <p>The overriding theme seems to be a combination of circumstances:</p>
  
  <ul>
  <li>A C application is linked to more than one C++ library</li>
  <li>More than one version of libstdc++ was used during compilation</li>
  <li>Generally the second version of C++ used comes from a binary-only implementation of libGL</li>
  <li>The problem does not occur when linking your library with a C++ application, only with a C application</li>
  </ul>
  
  <p>The "solution" is to explicitly link your library with libstdc++ and possibly also with libGL, forcing the order of linking. </p>
  
  <p>After trying many combinations with my code, the only solution that I found that works is the <code>LD_PRELOAD="libGL.so libstdc++.so.6" ruby scriptname</code> option. That is, none of the compile-time linking solutions made any difference.</p>
  
  <p>My understanding of the issue is that the C++ runtime is not being properly initialized. By forcing the order of linking you bootstrap the initialization process and it works. The problem occurs only with C applications calling C++ libraries because the C application is not itself linking to libstdc++ and is not initializing the C++ runtime. Because using SWIG (or boost::python) is a common way of calling a C++ library from a C application, that is why SWIG often comes up when researching the problem.</p>
  
  <p>Is anyone out there able to give more insight into this problem? Is there an actual solution or do only workarounds exist?</p>
  
  <p>Thanks.</p>