Modify

Ticket #2347 (closed Bugs: fixed)

Opened 6 years ago

Last modified 6 years ago

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

Reported by: dphilp@… Owned by: vladimir_prus
Milestone: Boost 1.37.0 Component: build
Version: Boost 1.36.0 Severity: Problem
Keywords: Cc:

Description

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.

Attachments

crasher.txt Download (31.9 KB) - added by Dave Philp <dphilp@…> 6 years ago.
non-crasher.txt Download (32.3 KB) - added by Dave Philp <dphilp@…> 6 years ago.

Change History

comment:1 Changed 6 years ago by 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@…

comment:2 Changed 6 years ago by 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.)

comment:3 Changed 6 years ago by 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

comment:4 Changed 6 years ago by vladimir_prus

  • Owner set to vladimir_prus
  • Component changed from None to 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?

comment:5 Changed 6 years ago by 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.)

Changed 6 years ago by Dave Philp <dphilp@…>

Changed 6 years ago by Dave Philp <dphilp@…>

comment:6 Changed 6 years ago by 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.

comment:7 Changed 6 years ago by vladimir_prus

  • Status changed from new to closed
  • Resolution set to 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.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.