SIGSEGV in _dl_fini
<p>I was hoping for some insights into debugging a problem I have been wrestling with for two days now. This is the situation</p>

<ul>
<li>I am working on two shared object files, let's call them <code>libMyA.so</code> and <code>libMyB.so</code>, that are part of a product.</li>
<li>These two shared object files each link two static library, <code>libMyC.a</code> and <code>libMyD.a</code></li>
<li><code>libMyA.so</code> and <code>libMyB.so</code> I have unit tests which are basically command line executables that invoke some of the functions exported by the shared objects, <code>blackboxA</code> and <code>blackboxB</code>.</li>
<li><code>libMyB.so</code> makes used of functions exported by <code>libMyA.so</code>. A few functions of <code>libMyA.so</code> are invoked in the init function of <code>libMyB.so</code> (just the generation of a few STL containers).</li>
</ul>

<p>What happens is this:</p>

<ul>
<li><code>blackboxA</code> runs smooth and passes all tests.</li>
<li><code>blackboxB</code> also passes all tests, but upon termination it raises a <code>SIGSEGV</code>.</li>
</ul>

<p>gdb tells me that the <code>SIGSEGV</code>happens during execution of the finalizer of <code>libMyB.so</code> inside the destructor of a <code>std::basic_string&lt;char&gt;</code> object:</p>

<pre><code>#0  0x00007ffff74a0bc3 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff74a0c13 in std::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;::~basic_string() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x00007ffff6b6cd1d in __cxa_finalize (d=0x7ffff7dd4d80) at cxa_finalize.c:56
#3  0x00007ffff7b1d7b6 in __do_global_dtors_aux () from ./libMinosCVC.so.3
#4  0x00007fffffffe3a0 in ?? ()
#5  0x00007fffffffe480 in ?? ()
#6  0x00007ffff7b9a541 in _fini () from ./libMinosCVC.so.3
#7  0x00007fffffffe480 in ?? ()
#8  0x00007ffff7de992d in _dl_fini () at dl-fini.c:259
</code></pre>

<p>I am aware, that std::string objects defined at global or namespace scope in a static library may be problematic when that static library is linked by more than one shared object in the process, and have skimmed <code>libMyC.a</code> and <code>libMyD.a</code> for string objects at those scoped without success so far.</p>

<p>I have also modified <code>blackboxB</code> to the extent where the main function only consisted of a <code>return 0</code> - the <code>SIGSEGV</code> persisted. If I modify <code>libMyB.so</code> to longer call anything from <code>libMyA.so</code> in its init function the <code>SIGSEGV</code>vanishes.</p>

<p>Is there any means I am not aware of for detecting the actual object that the libc is trying to clean up when the SIGSEGV happens? gdb did point out the <code>std::string</code> destructor, but nothing beyond that (even access to <code>std::string</code> members was not possible). valgrind was not much help, either...</p>

<p>Oh, I almost forgot the cherry on top: When built with -O0 everything works, only the -O2 build crashes.</p>

<p>Thanks for any input on this nightmare...</p>