Re: [boost] [thread] Fails on 64-bit Linux?

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-13 05:01:56

Martin Wille <mw8329_at_[hidden]> writes:

> Anthony Williams wrote:
>> Martin Wille <mw8329_at_[hidden]> writes:
>> 
>>> John Maddock wrote:
>>>> Anyone any ideas about the remaining thread library regressions: 
>>>> http://beta.boost.org/development/tests/trunk/developer/issues_release_.html#thread 
>>>> they're causing Boost.Regex failures as well apart from anything else :-(
>>> That one is twofold. There's an error due to a resource limit (which I
>>> can lift). There's a second error described in
>>> http://svn.boost.org/trac/boost/ticket/1323
>> 
>> The assertion failure is not a bug in the thread library. It is a bug in the
>> way the test is run: when the resource limit failure is thrown, a condition
>> variable is destroyed whilst there are still threads waiting on it.
>> 
>> I am not sure which aspect of the test-running is causing that problem.
>
> The tests simply are run with a limit on RLIMIT_NPROC.

If that limits the number of threads, some of my tests will break. The
shared_mutex test spawns 100 threads in order to stress-test it, for example.

> Or are you referring to the code of the test itself?

I'm referring to the code of the executable test rather than the test
environment.

In the barrier test, for example, if the test can't launch enough threads, the
already-launched threads will be waiting on the barrier. The test thread will
then abort, destroying the barrier, whilst still having threads waiting. This
is a bug in the test: the existing threads should be interrupted and joined
under such circumstances.

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL