Re: [Boost-users] linking to boost thread exposes static initialisation order fiasco in ublas?

Subject: Re: [Boost-users] linking to boost thread exposes static initialisation order fiasco in ublas?
From: Roland Bock (rbock_at_[hidden])
Date: 2008-09-19 07:05:03

Hi David,

just for completeness, I stripped my binary, too. No problem on my 
machine, sorry.

Regarding gcc:
If upgrading is an option on OS X, personally, I would try it. With 
language support for C and C++ only, it is not that hard to compile gcc 
(at least on Linux).

Regarding Valgrind:
If valgrind is not available for OS X, there have to be other tools to 
do similar analysis. I read the efence is available, for instance.

Anyways, my suggestion is to get tool-support (and try to upgrade).

Regards,

Roland

David Philp wrote:
> 
> Dear Roland
> 
> Thanks for trying it out, and thanks also because I assume you glanced 
> at the code and there isn't an obvious mistake!
> 
> The problem is the same whether I link statically or dynamically.
> 
>> In my previous company, we had some weird problems with the first 4.x 
>> versions of gcc, so maybe you should try to upgrade? Of course, I 
>> cannot promise that this would help.
> 
> I just used bjam release -d+2 and ran the commands step-by-step myself.  
> It turns out that the /strip/ command exposes the problem.  If I take 
> the "debug" executable and run strip on it, it all crashes.  That 
> suggests to me that it's not GCC.  (OS X 10.5.5 uses GCC 4.0.1, which is 
> not the notorious 4.0.0.)
> 
> As I understand it, valgrind is a Linux-only package.
> 
> Thanks for your suggestions.  I'm convinced that this is is a bug, but I 
> don't have anything like the expertise to chase it down.
> 
> David
> 
> 
> On 19/09/2008, at 6:42 AM, Dr. Roland Bock wrote:
> 
>> Hi,
>>
>> this is probably not very helpful, but: It works fine on my machine.
>>
>> Linux 2.6.24-19-generic x86_64 GNU/Linux
>> gcc 4.2.3
>>
>> I linked to boost_thread dynamically:
>> /usr/bin/c++   -Wall -Wreorder -Wnon-virtual-dtor 
>> -Wno-non-template-friend -Woverloaded-virtual -Wsign-promo -Wextra 
>> -fvisibility=hidden -D_GNU_SOURCE   -fPIC 
>> "CMakeFiles/DateTime.dir/DateTime.o" 
>> "CMakeFiles/DateTime.dir/__/generated/revision.o"   -o DateTime 
>> -rdynamic -L/home/rbock/Software/Sources/BoostTests/trunk/src 
>> -L/home/rbock/Software/Binaries/boost/1.36/lib 
>> -lboost_date_time-gcc42-mt-1_36 -lboost_thread-gcc42-mt-1_36 
>> -lboost_date_time-gcc42-mt-1_36 -lboost_system-gcc42-mt-1_36 -lpthread 
>> -Wl,-rpath,/home/rbock/Software/Sources/BoostTests/trunk/src:/home/rbock/Software/Binaries/boost/1.36/lib 
>>
>>
>>
>> In my previous company, we had some weird problems with the first 4.x 
>> versions of gcc, so maybe you should try to upgrade? Of course, I 
>> cannot promise that this would help.
>>
>> If valgrind is available for your system, you might also try to use it 
>> to gather more details of what is happening with the memory. The 
>> report on my machine is clean, but on your machine something should be 
>> shown.
>>
>>
>> Regards,
>>
>> Roland
>>
>>
>> David Philp wrote:
>>> Hi
>>> This is a weird issue, and I'm by no means sure that my description 
>>> is correct.  It might be a newbie misunderstanding, but it is weird 
>>> behaviour and I would appreciate any help in getting to the bottom of 
>>> it.
>>> Here is a minimal example that exhibits the issue: ("zeromain.cpp")
>>> #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;
>>> }
>>> When compiled [with bjam release] and linked to libboost_thread it 
>>> gives a "bus error".  The backtrace is appended to this email.  It 
>>> works fine in debug mode.
>>> You can see that I have introduced boost.thread but not yet actually 
>>> used the thread library in any way.  If I take out either the 
>>> include, or don't link to the lib, the bug goes away.
>>> Thanks in advance for any help or suggestions!  Details below.
>>> David
>>> Mac OS X 1.5.5, boost 1.36.  Intel CPU.
>>> The boost libraries are in $DYLD_LIBRARY_PATH.
>>> Jamroot contains
>>> exe zm
>>>  : zeromain.cpp /sage//boost_thread
>>>  : <include>boost
>>>  ;
>>> ("sage" is a separate project whose Jamroot contains
>>> lib boost_thread : : 
>>> <file>local/lib/boost/libboost_thread-xgcc40-mt-1_36.a ;
>>> It is a regular build of the boost libraries.)
>>> Backtrace:
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
>>> 0x00001f24 in boost::numeric::ublas::coordinate_matrix<double, 
>>> boost::numeric::ublas::basic_row_major<unsigned long, int>, 0ul, 
>>> boost::numeric::ublas::unbounded_array<unsigned long, 
>>> std::allocator<unsigned long> >, 
>>> boost::numeric::ublas::unbounded_array<double, std::allocator<double> 
>>> >  >::coordinate_matrix ()
>>> (gdb) bt
>>> #0  0x00001f24 in boost::numeric::ublas::coordinate_matrix<double, 
>>> boost::numeric::ublas::basic_row_major<unsigned long, int>, 0ul, 
>>> boost::numeric::ublas::unbounded_array<unsigned long, 
>>> std::allocator<unsigned long> >, 
>>> boost::numeric::ublas::unbounded_array<double, std::allocator<double> 
>>> >  >::coordinate_matrix ()
>>> #1  0x8fe12e76 in 
>>> __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE () 
>>> #2  0x8fe0e723 in 
>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
>>> #3  0x8fe0e809 in 
>>> __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
>>> #4  0x8fe04102 in __dyld__ZN4dyld24initializeMainExecutableEv ()
>>> #5  0x8fe07b5f in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_ ()
>>> #6  0x8fe01872 in 
>>> __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl ()
>>> #7  0x8fe01037 in __dyld__dyld_start ()
>>> _______________________________________________
>>> Boost-users mailing list
>>> Boost-users_at_[hidden]
>>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
> 
> ==================================
> David J Philp
> Postdoctoral Fellow
> National Centre for Epidemiology and Population Health
> Building 62, cnr Mills Rd & Eggleston Rd
> The Australian National University
> Canberra ACT 0200 Australia
> 
> T: [phone]
> F: [phone]
> M: 0423 535 397
> W: http://nceph.anu.edu.au/
> 
> CRICOS Provider #00120C
> 
> 
> 
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users