'Bus error' on OS X when combining ublas and thread

[dphilp@…]

The following code compiles but gives an error on OS X 10.5.5:

#include <boost/numeric/ublas/matrix_sparse.hpp>
#include <boost/thread.hpp>

int main (int argc, char * argv[]) 
{
  boost::numeric::ublas::coordinate_matrix<double> cm;
  cm.resize(3,3, false);
  return 0;
}

Jamroot is:

lib boost_thread : : <file>/Users/djp/sg/sage-3.1.1/local/lib/boost/libboost_thread-xgcc40-mt-1_36.a ;

exe ut
  : main.cpp boost_thread
  : <include>boost 
  ;

The program does not crash if: (1) I don't link to boost.thread, or remove boost/thread.hpp from main.cpp. (2) I don't 'strip' the executable before running it.

The error is independent of whether I link statically or dynamically, and whether I compile in 'debug' or 'release' mode. (Though it doesn't appear in 'debug' mode unless I strip the executable myself.)

The error doesn't depend on coordinate matrix, it happens just the same if I use a ublas::vector (and include the relevant header.)

Anyway, the above is about as small an example as I can figure out, and I certainly don't have the skills to go any further.

[Dave Philp <dphilp@…>]

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@…

[Dave Philp <dphilp@…>]

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.)

[Dave Philp <dphilp@…>]

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

[Vladimir Prus]

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?

[Dave Philp <dphilp@…>]

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.)

[Dave Philp <dphilp@…>]

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.

[Vladimir Prus]

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.