Re: [boost] Regressions in your Boost libraries as of 2005-07-19

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2005-07-21 10:21:02

On Jul 19, 2005, at 1:20 PM, Joel de Guzman wrote:

> Douglas Gregor wrote:
>> You are receiving this report because one or more of the libraries you
>> maintain has regression test failures that are not accounted for.
>> A full version of the report is sent to the Boost developer's mailing
>> list.
>>
>> Detailed report:
>>    
>> http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/ 
>> issues.html
>>
>> There are failures in these libraries you maintain:
>>   spirit (1)
>>
>> |spirit|
>>   owi_mt_tests:  gcc-3_3-darwin
>
> I do not know how to fix this last remaining problem. I
> desperately need some help!

After a few tries I was able to catch it in gdb. Here's a backtrace:

#0  0x9004310c in kill ()
#1  0x9009fb9c in abort ()
#2  0x001d7c14 in __eprintf () at  
/usr/include/gcc/darwin/3.3/c++/bits/stl_vector.h:424
#3  0x001c2784 in boost::mutex::~mutex() (this=0x60d40, __in_chrg=2) at  
/Volumes/scratch/dgregor/BoostRegressionTesting/boost/libs/thread/src/ 
mutex.cpp:211
#4  0x001c2708 in boost::mutex::~mutex() (this=0x60d40) at  
/Volumes/scratch/dgregor/BoostRegressionTesting/boost/libs/thread/src/ 
mutex.cpp:208
#5  0x00003300 in __tcf_1 () at  
../boost/spirit/core/non_terminal/impl/object_with_id.ipp:130
#6  0x9002ce38 in exit ()
#7  0x0000291c in _start (argc=-1610575468, argv=0xa000919c, envp=0x1)  
at /SourceCache/Csu/Csu-47/crt.c:267
#8  0x8fe1a278 in __dyld__dyld_start ()

The problem only shows up on my dual-processor G5, and never seemed to  
happen on single-processor systems, so we have some kind of race  
condition. Looking more carefully at the Spirit source, I see this:

#ifdef BOOST_SPIRIT_THREADSAFE
                 static boost::mutex mutex;
                 boost::mutex::scoped_lock lock(mutex);
#endif

I don't think that's valid, because two threads could try to initialize  
the static at the same time. We'd need to do some other kind of locking  
in here, then create the mutex on the heap.

        Doug