Boost C++ Libraries: Ticket #2347: 'Bus error' on OS X when combining ublas and thread

Thu, 18 Sep 2008 23:26:03 GMT

I should have mentioned: I have not filed it against ublas, thread, or even build because I have no idea which is causing the problem. I'm happy to help chase it down, and can be contacted at dphilp@…

Sun, 21 Sep 2008 23:13:19 GMT

The problem is that 'strip' should not be run without options---doing this strips too much out of the binary. Running strip with the -S and -x options seems to be appropriate on OS X but I don't have the expertise to verify this. (Thanks to Zeljko Vrba for figuring this out.)

Sun, 21 Sep 2008 23:39:40 GMT

I would appreciate being kept in the loop wrt this bug, please send me an email when you get around to looking at it. D

component changed; owner set

Vladimir Prus — Mon, 29 Sep 2008 16:37:00 GMT

owner set to Vladimir Prus
component None → build

Do I understand correctly that if you build in debug mode, application works, but if you strip it with just 'strip', it crashes? What happens if you strip with "strip -u -r"? Does the application actually work if stripped with "strip -S -x"? Can you run 'nm' on a binary that crashes and a binary that does not, and post both outputs here?

Mon, 29 Sep 2008 23:35:40 GMT

Do I understand correctly that if you build in debug mode, application works, but if you strip it with just 'strip', it crashes?

Correct.

What happens if you strip with "strip -u -r"?

Bus error.

Does the application actually work if stripped with "strip -S -x"?

Well, the application above doesn't actually do much! But it doesn't crash. If I add in a few headers and send the cm matrix to std::cout, everything works as expected:

#include <boost/thread.hpp>
#include <boost/numeric/ublas/matrix_sparse.hpp>
#include <boost/numeric/ublas/io.hpp>
#include <iostream>
int main (int argc, char * argv[])
{
  boost::numeric::ublas::coordinate_matrix<double> cm;
  cm.resize(3, 3, false);
  cm(0, 0) = 1;
  cm(1, 1) = 2;
  cm(2, 2) = 3;
  std::cout << cm << std::endl;
  return 0;
}

In the above, if you compile and run with bjam debug and strip (no options), it crashes before giving any output. (If you comment out #include boost/thread.hpp, it works as expected.)

attachment set

Mon, 29 Sep 2008 23:36:06 GMT

attachment → crasher.txt

attachment set

Mon, 29 Sep 2008 23:36:18 GMT

attachment → non-crasher.txt

Mon, 29 Sep 2008 23:37:42 GMT

I have attached the output of "nm" to this ticket. It's for the new version above with the io stuff.

I've never used nm before so don't know if this is what you're after.

status changed; resolution set

Vladimir Prus — Tue, 30 Sep 2008 06:19:42 GMT

status new → closed
resolution → fixed

Thanks, the output you've posted is what I was looking for. Diffing the outputs gives this:

--- non-crasher.txt     2008-09-30 09:56:43.000000000 +0400
+++ crasher.txt 2008-09-30 09:56:26.000000000 +0400
@@ -1,8 +1,4 @@
-0000f00c D _NXArgc
-0000f008 D _NXArgv
-0000c812 s __GLOBAL__I_main
          U __Unwind_Resume
-0000c780 s __Z41__static_initialization_and_destruction_0ii
....
-0000f000 D ___progname
-00002346 t ___tcf_0
-00002124 t __dyld_func_lookup
 00001000 A __mh_execute_header
-0000f004 D _environ
          U _exit
-00002132 T _main
-0000f010 d dyld__mach_header
-00002110 t dyld_stub_binding_helper
-000020d0 T start

which surely looks very scary. I was not able to find a definite explanation why strip breaks a binary like this, so I presume we're using strip in some way it was not meant to, which breaks on newer OSX. But to make progress, I've switched to use -S -x. Feel free to open another ticket if you find a "better" way to strip binaries.