Anyone any ideas about the remaining thread library regressions: http://beta.boost.org/development/tests/trunk/developer/issues_release_.html... they're causing Boost.Regex failures as well apart from anything else :-( Thanks, John.
John Maddock wrote:
Anyone any ideas about the remaining thread library regressions: http://beta.boost.org/development/tests/trunk/developer/issues_release_.html... 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 HTH, m
Martin Wille <mw8329@yahoo.com.au> writes:
John Maddock wrote:
Anyone any ideas about the remaining thread library regressions: http://beta.boost.org/development/tests/trunk/developer/issues_release_.html... 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. 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
Anthony Williams wrote:
Martin Wille <mw8329@yahoo.com.au> writes:
John Maddock wrote:
Anyone any ideas about the remaining thread library regressions: http://beta.boost.org/development/tests/trunk/developer/issues_release_.html... 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. Or are you referring to the code of the test itself? Regards, m
Martin Wille <mw8329@yahoo.com.au> writes:
Anthony Williams wrote:
Martin Wille <mw8329@yahoo.com.au> writes:
John Maddock wrote:
Anyone any ideas about the remaining thread library regressions: http://beta.boost.org/development/tests/trunk/developer/issues_release_.html... 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
Anthony Williams <anthony_w.geo@yahoo.com> writes:
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.
Martin, could you check the attached version of test_barrier.cpp in your environment: it should gracefully interrupt all threads on an exception, and thus avoid the assertion failure. Thanks, 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
Anthony Williams wrote:
Anthony Williams <anthony_w.geo@yahoo.com> writes:
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.
Martin, could you check the attached version of test_barrier.cpp in your environment: it should gracefully interrupt all threads on an exception, and thus avoid the assertion failure.
This seems to work. I tried various settings of RLIMIT_NPOC and I was unable to produce the assertion error. Regards, m
Martin Wille <mw8329@yahoo.com.au> writes:
Anthony Williams wrote:
Anthony Williams <anthony_w.geo@yahoo.com> writes:
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.
Martin, could you check the attached version of test_barrier.cpp in your environment: it should gracefully interrupt all threads on an exception, and thus avoid the assertion failure.
This seems to work. I tried various settings of RLIMIT_NPOC and I was unable to produce the assertion error.
Thanks. I've checked in the fix to test_barrier, and I'll come up with similar fixes for the other tests too. 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
Martin Wille wrote:
John Maddock wrote:
Anyone any ideas about the remaining thread library regressions: http://beta.boost.org/development/tests/trunk/developer/issues_release_.html... 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
I'm havint the same problem for Interprocess in your test machine (Martin Wille x86_64) (http://tinyurl.com/2dtmtq): Run [2007-10-29 09:12:58 UTC]: fail terminate called after throwing an instance of 'boost::thread_resource_error' what(): boost::thread_resource_error EXIT STATUS: 134 All Interprocess tests launching a thread seem to be suffering the same problem. And I don't think I launch too many threads (5 at maximum) to test a condition variable or mutex. Can we fix this or I should change the number to 3? Regards, Ion
Ion Gaztañaga wrote:
Martin Wille wrote:
John Maddock wrote:
Anyone any ideas about the remaining thread library regressions: http://beta.boost.org/development/tests/trunk/developer/issues_release_.html... 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
I'm havint the same problem for Interprocess in your test machine (Martin Wille x86_64) (http://tinyurl.com/2dtmtq):
Run [2007-10-29 09:12:58 UTC]: fail
terminate called after throwing an instance of 'boost::thread_resource_error' what(): boost::thread_resource_error
EXIT STATUS: 134
All Interprocess tests launching a thread seem to be suffering the same problem. And I don't think I launch too many threads (5 at maximum) to test a condition variable or mutex. Can we fix this or I should change the number to 3?
I wonder where all the threads come from. RLIMIT_NRPOC is set to 10 by default. That should be sufficient for 1 (shell) + 1 (test programm) + 1 (possible artificial thread of the MT implementation) + 5 threads. I suspect the limit gets reduced drastically by the shell that gets invoked to run the test binary. Apparently, all thread-related tests are affected. I'll raise the limit globally, once it is sorted out where the (additional) assertion errors in some of the tests exactly comes from. Regards, m
"John Maddock" <john@johnmaddock.co.uk> writes:
Anyone any ideas about the remaining thread library regressions: http://beta.boost.org/development/tests/trunk/developer/issues_release_.html... they're causing Boost.Regex failures as well apart from anything else :-(
No idea at all. My Linux test machine is running 64-bit Kubuntu on x86, and everything passes there. It's throwing a thread_resource_error, so something isn't initializing properly (could be a mutex or a condition variable failing to initialize, or a thread failing to start). 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
participants (4)
-
Anthony Williams -
Ion Gaztañaga -
John Maddock -
Martin Wille