<div dir="ltr">This is a known issue that we've discussed in the past (though I can't find a record of the discussion right now). The issue, in the general case, is that it's possible for a common variable (local static or static data member of a class template specialization or variable template specialization) to have static initialization in one translation unit and dynamic initialization in another.<div>
<br></div><div>The approach we came up with was:<div><br></div><div> * put the variable and its guard variable in a COMDAT together, as the ABI document suggests (LLVM doesn't yet have the machinery for this)</div><div>
* if we constant-initialize a common variable, but we can't prove that every other translation unit that sees it will also constant-initialize it, emit a guard variable statically initialized to the 'already initialized' value</div>
<div><br></div><div>... but we've not implemented anything like this yet.</div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 7, 2014 at 3:11 PM, Kevin Locke <span dir="ltr"><<a href="mailto:kevin@kevinlocke.name" target="_blank">kevin@kevinlocke.name</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello All,<br>
<br>
I've been trying to track down an EXC_BAD_ACCESS error (Bus error: 10)<br>
which occurs during static initialization when linking a program using<br>
boost to a library using boost. The problem occurred, for me, with<br>
QuantLib, but it has been reported to occur with mlpack[1] and likely<br>
affects other boost-using libraries as well. I have determined that<br>
the issue occurs when a library is compiled with -std=c++11 and the<br>
program is not (or vice versa).<br>
<br>
Now that I have identified that the issue is C++11 ABI compatibility,<br>
I can easily avoid the issue on my systems. However, I have brought<br>
it to your attention in the hopes that it can either made easier to<br>
identify or the compatibility can be improved to save future users the<br>
effort spent debugging to identify the same issue.<br>
<br>
For reference, the issue occurs when using "Apple LLVM version 5.1<br>
(clang-503.0.38) (based on LLVM 3.4svn)" on Mac OS X 10.9.2 with Boost<br>
1.55.0 using the following example program (please excuse the abuse of<br>
Boost internals to make a minimal test case):<br>
<br>
-8<--libcrash11.cpp---------------------------------------------------<br>
#include <boost/math/special_functions/lanczos.hpp><br>
<br>
double libfunc() {<br>
return boost::math::lanczos::lanczos17m64::lanczos_sum(1.0);<br>
}<br>
-8<--libcrash11.cpp---------------------------------------------------<br>
<br>
-8<--crash11.cpp------------------------------------------------------<br>
#include <boost/math/special_functions/lanczos.hpp><br>
<br>
int main(int,char**) {<br>
boost::math::lanczos::lanczos17m64::lanczos_sum(1.0);<br>
return 0;<br>
}<br>
-8<--crash11.cpp------------------------------------------------------<br>
<br>
Compiled as follows:<br>
clang++ -dynamiclib -o libcrash11.dylib libcrash11.cpp<br>
clang++ -std=c++11 -L. -lcrash11 -o crash11 crash11.cpp<br>
<br>
Now the binary compiled in C++11 mode has<br>
double boost::math::lanczos::lanczos17m64::lanczos_sum<double>(double const&)::num<br>
inside the .__TEXT.__const segment while the other has this symbol inside<br>
the .__DATA.__data segment.<br>
<br>
Executing crash11 in a debugger shows that the program stops with<br>
EXC_BAD_ACCESS when attempting to initialize the copy of<br>
double boost::math::lanczos::lanczos17m64::lanczos_sum<double>(double const&)::num<br>
inside the crash11.__TEXT.__const segment (which is presumably mapped<br>
read-only).<br>
<br>
As a non-expert, I would guess that in C++11 the value of the symbol<br>
can be determined at compile time and placed in the const segment<br>
while in C++98 mode it must be initialized at runtime and that when<br>
linked together the initialization is applied to both occurrences of<br>
the symbol, causing the crash. But I may be completely off-base with<br>
this guess.<br>
<br>
So, my question to you is: Can the situation be improved? Either by<br>
avoiding the crash by applying the initialization only to the symbol<br>
in .__DATA.__data or could it generate a linker or loader error with a<br>
message that indicates the C++11 ABI as a potential cause of the<br>
incompatibility? Or perhaps something else?<br>
<br>
In either case users would be advised to not link different C++<br>
dialects together. But I'm afraid we users are perpetually finding<br>
ways to screw such things up (or, at least, I am).<br>
<br>
Cheers,<br>
Kevin<br>
<br>
<br>
1. <a href="http://trac.research.cc.gatech.edu/fastlab/ticket/296" target="_blank">http://trac.research.cc.gatech.edu/fastlab/ticket/296</a><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div></div></div>