[regex, threads, test] Exception problems
In another posting, John Maddock wrote:
... I'm a little concerned about some of the regex library tests which haven't changed in ages, but are none the less failing due to exceptions thrown from Boost.Thread and Boost.Test. I'm not sure that this is necessarily these libraries fault, but we really ought to try and get to the cause of this...
I'm worried about these too. I'm also getting exception related dialog boxes during Windows smoke tests; they don't even say what program they are coming out of. Not sure if that is the same problem; I'll try to isolate one of them and report details. Which specific test are you concerned about? regex_regress_threaded? Any others? --Beman
Beman Dawes wrote:
In another posting, John Maddock wrote:
... I'm a little concerned about some of the regex library tests which haven't changed in ages, but are none the less failing due to exceptions thrown from Boost.Thread and Boost.Test. I'm not sure that this is necessarily these libraries fault, but we really ought to try and get to the cause of this...
I'm worried about these too. I'm also getting exception related dialog boxes during Windows smoke tests; they don't even say what program they are coming out of. Not sure if that is the same problem; I'll try to isolate one of them and report details.
Which specific test are you concerned about? regex_regress_threaded? Any others?
Yes, currently just http://tinyurl.com/yqx58t is failing because of a thread resource issue: I checked in some changes to that test case so it does fail anymore if thread creation fails (the rationale being "it's not my fault"), but I'm seeing sporadic failures on the same test from Boost.Test throwing a system_error *before* cpp_main is reached. It could be an issue with whatever the load is on the test machine sometimes tripping that test up. Likewise there are quite a few Boost.Thread failures http://beta.boost.org/development/tests/trunk/developer/issues_release_.html... on the same platform: Anthony any progress on these? Likewise Thread's support for Borland seems to be broken at present :-( John.
Yes, currently just http://tinyurl.com/yqx58t is failing because of a thread resource issue: I checked in some changes to that test case so it does fail anymore if thread creation fails (the rationale being "it's not my fault"), but I'm seeing sporadic failures on the same test from Boost.Test throwing a system_error *before* cpp_main is reached. It could be an issue with whatever the load is on the test machine sometimes tripping that test up. Likewise there are quite a few Boost.Thread failures http://beta.boost.org/development/tests/trunk/developer/issues _release_.html#thread on the same platform: Anthony any progress on these?
Likewise Thread's support for Borland seems to be broken at present :-(
Some Wave tests do fail because of spurious thread exceptions as well (here: http://tinyurl.com/2cfbzb). On some platforms the Wave test seems to crash during application cleanup without any visible messages (here: http://tinyurl.com/26varp, http://tinyurl.com/24vmbv), judging from the experiences before this might be because of the recent changes in the thread library as well, but I'm certainly not sure... Regards Hartmut
Hartmut Kaiser <hartmut.kaiser <at> gmail.com> writes:
Some Wave tests do fail because of spurious thread exceptions as well (here: http://tinyurl.com/2cfbzb).
I'd like to know which resource limits have been exceeded
On some platforms the Wave test seems to crash during application cleanup without any visible messages (here: http://tinyurl.com/26varp, http://tinyurl.com/24vmbv), judging from the experiences before this might be because of the recent changes in the thread library as well, but I'm certainly not sure...
Those wave tests pass fine on my linux box, but it's possible that it's due to TSS cleanup. Roland has expressed concern about the way that thread_specific_ptr is used in spirit (and hence in Wave). Anthony
Anthony,
Some Wave tests do fail because of spurious thread exceptions as well (here: http://tinyurl.com/2cfbzb).
I'd like to know which resource limits have been exceeded
I have no access to the platforms in question, all I can tell is that a 'boost::thread_resource_error' has been thrown.
On some platforms the Wave test seems to crash during application cleanup without any visible messages (here: http://tinyurl.com/26varp, http://tinyurl.com/24vmbv), judging from the experiences before this might be because of the recent changes in the thread library as well, but I'm certainly not sure...
Those wave tests pass fine on my linux box, but it's possible that it's due to TSS cleanup. Roland has expressed concern about the way that thread_specific_ptr is used in spirit (and hence in Wave).
This was a misunderstanding from Rolands side which has been discussed and cleared off list. Regards Hartmut
Hartmut Kaiser wrote:
Anthony,
Some Wave tests do fail because of spurious thread exceptions as well (here: http://tinyurl.com/2cfbzb). I'd like to know which resource limits have been exceeded
I have no access to the platforms in question, all I can tell is that a 'boost::thread_resource_error' has been thrown.
Quite likely, the number of threads exceeded a limit imposed on the test machine. This is the same as for other Boost.Thread related failures we've seen recently from my machine. The limit has been raised globally, so if a test does not spawn many threads then it should not fail due to this condition anymore. Regards, m
Martin,
Some Wave tests do fail because of spurious thread exceptions as well (here: http://tinyurl.com/2cfbzb). I'd like to know which resource limits have been exceeded
I have no access to the platforms in question, all I can tell is that a 'boost::thread_resource_error' has been thrown.
Quite likely, the number of threads exceeded a limit imposed on the test machine. This is the same as for other Boost.Thread related failures we've seen recently from my machine.
The limit has been raised globally, so if a test does not spawn many threads then it should not fail due to this condition anymore.
The interesting piece of information here is, that the Wave tests do not spawn any additional threads. Wave links against Boost.Thread only because it uses Boost.Pool which depends on Boost.Thread synchronization primitives. Regards Hartmut
At 10:10 PM -0600 11/25/07, Hartmut Kaiser wrote:
Martin,
Some Wave tests do fail because of spurious thread exceptions as well (here: http://tinyurl.com/2cfbzb). I'd like to know which resource limits have been exceeded
I have no access to the platforms in question, all I can tell is that a 'boost::thread_resource_error' has been thrown.
Quite likely, the number of threads exceeded a limit imposed on the test machine. This is the same as for other Boost.Thread related failures we've seen recently from my machine.
The limit has been raised globally, so if a test does not spawn many threads then it should not fail due to this condition anymore.
The interesting piece of information here is, that the Wave tests do not spawn any additional threads. Wave links against Boost.Thread only because it uses Boost.Pool which depends on Boost.Thread synchronization primitives.
Just a note: I checked in some (minor) changes to Boost.Pool last week. I don't think they could be causing these failures, but I figured that I should speak up.... -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:001501c82eb5$7a293ba0$3ce70c52@fuji...
Beman Dawes wrote:
Which specific test are you concerned about? regex_regress_threaded? Any others?
Yes, currently just http://tinyurl.com/yqx58t is failing because of a thread resource issue: I checked in some changes to that test case so it does fail anymore if thread creation fails (the rationale being "it's not my fault"), but I'm seeing sporadic failures on the same test from Boost.Test throwing a system_error *before* cpp_main is reached. It could be an issue with whatever the load is on the test machine sometimes tripping that test up.
I've commited changes into Program Execution Monitor, so system_error is caught and reported inside cpp_main.ipp. It should shed some light on the cause of failure. I also added failed expression string to the system_error. Gennadiy
John Maddock wrote:
Beman Dawes wrote:
In another posting, John Maddock wrote:
... I'm a little concerned about some of the regex library tests which haven't changed in ages, but are none the less failing due to exceptions thrown from Boost.Thread and Boost.Test. I'm not sure that this is necessarily these libraries fault, but we really ought to try and get to the cause of this... I'm worried about these too. I'm also getting exception related dialog boxes during Windows smoke tests; they don't even say what program they are coming out of. Not sure if that is the same problem; I'll try to isolate one of them and report details.
Which specific test are you concerned about? regex_regress_threaded? Any others?
Yes, currently just http://tinyurl.com/yqx58t is failing because of a thread resource issue
In the hope of eventually being able to run tests unattended, I'm imposing a lot of resource limits on tests now (after I have seen all kinds of excessive resource usage by broken tests). Among those, there is a limit on the number of threads that can be executed. I raised the thread-limit globally, so the number of tests suffering from thread resource problems should drop significantly. Regards, m
John Maddock <john <at> johnmaddock.co.uk> writes:
Likewise there are quite a few Boost.Thread failures
http://beta.boost.org/development/tests/trunk/developer/issues_release_.html...
on the same platform: Anthony any progress on these?
The condition and shared_mutex tests are timeouts. The condition test takes over 100s by design. The shared_mutex test shouldn't time out,, but it spawns lots of threads, so a heavily-loaded machine could cause it to take a long time. I don't see any failures on linux (kubuntu 7.10 x86_64) with gcc 4.1.3. The once failure is concerning. I'd be interested to know where the resource error comes from.
Likewise Thread's support for Borland seems to be broken at present
I didn't think there were any major issues with Borland. I'm fairly sure the siliconman failures are due to things not rebuilding when they should have done, but they haven't been run for a while --- my fix to the headers to allow the header changes to force a rebuild was after then. Are you seeing some problems? Anthony
Anthony Williams wrote:
Likewise Thread's support for Borland seems to be broken at present
I didn't think there were any major issues with Borland. I'm fairly sure the siliconman failures are due to things not rebuilding when they should have done, but they haven't been run for a while --- my fix to the headers to allow the header changes to force a rebuild was after then.
Are you seeing some problems?
Yep, with current SVN: borland.compile.c++ ..\..\..\bin.v2\libs\thread\build\borland-5.8.2\debug\thread ing-multi\thread.obj ..\..\..\libs\thread\src\win32\thread.cpp: Error E2096 ..\..\..\libs\thread\src\win32\thread.cpp 497: Illegal structure ope ration in function set_tss_data(const void *,shared_ptr<tss_cleanup_function>,vo id *,bool) *** 1 errors in Compile *** Same error with 5.6.4 and 5.8.2 compiler versions. John.
"John Maddock" <john@johnmaddock.co.uk> writes:
borland.compile.c++ ..\..\..\bin.v2\libs\thread\build\borland-5.8.2\debug\thread ing-multi\thread.obj ..\..\..\libs\thread\src\win32\thread.cpp: Error E2096 ..\..\..\libs\thread\src\win32\thread.cpp 497: Illegal structure ope ration in function set_tss_data(const void *,shared_ptr<tss_cleanup_function>,vo id *,bool) *** 1 errors in Compile ***
Same error with 5.6.4 and 5.8.2 compiler versions.
That's an unfortunate compiler bug: that line does "if(some-bool && some-shared_ptr)" line 151 does "if(the-same-shared_ptr)", so it's obviously context-sensitive. It does appear that this bug is fixed in borland 5.9.2, as the bcbboost tests all pass. Anyway, my Borland compiler seems to be working today (it's very temperamental --- some days nothing works), so I'll sort out a fix. 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
Beman Dawes wrote:
In another posting, John Maddock wrote:
... I'm a little concerned about some of the regex library tests which haven't changed in ages, but are none the less failing due to exceptions thrown from Boost.Thread and Boost.Test. I'm not sure that this is necessarily these libraries fault, but we really ought to try and get to the cause of this...
I'm worried about these too. I'm also getting exception related dialog boxes during Windows smoke tests; they don't even say what program they are coming out of. Not sure if that is the same problem; I'll try to isolate one of them and report details.
Three tests are failing (and popping up an exception dialog, causing much consternation!): simple_example_5 testtz_database testlocal_time_facet Ha! These tests don't even use Boost.Test or Boost.Threads at all! The first is from the Tokenizer library, the two others from Date-Time. simple_example_5 is just an assertion failure. Looks like the change John just committed broke something:-( --Beman
Beman Dawes wrote:
simple_example_5 is just an assertion failure. Looks like the change John just committed broke something:-(
Yep, that would be me! :-( Now fixed in SVN: what appeared to be a trivial patch turned out to be not *quite* so trivial after all. The lack of proper documentation doesn't help - the submitted Track patch was against a public member function with no docs - in fact none of the public member functions have docs as far as I can see :-( Looks like another library for the IBD folks to get their teeth into, in fact it could do with a spruce-and-brush-up all round really, any takers? Regards, John.
participants (7)
-
Anthony Williams -
Beman Dawes -
Gennadiy Rozental -
Hartmut Kaiser -
John Maddock -
Marshall Clow -
Martin Wille