[test] Causing regex regression?

Gennadiy, Would you know the likely reason for a boost::system_error being thrown in this test: http://tinyurl.com/yq2yya ? Glancing at the Boost.Test source this appears to be thrown when an internal Boost.Test assertion fails? Any ideas what's going on? Thanks, John.

John Maddock <john <at> johnmaddock.co.uk> writes:
Gennadiy,
Would you know the likely reason for a boost::system_error being thrown in this test: http://tinyurl.com/yq2yya ?
Glancing at the Boost.Test source this appears to be thrown when an internal Boost.Test assertion fails? Any ideas what's going on?
system_error is thrown in case if system level call failed. I am on vacation till the end of the week. I will try to look at this Sunday. Gennadiy

Gennadiy Rozental wrote:
John Maddock <john <at> johnmaddock.co.uk> writes:
Gennadiy,
Would you know the likely reason for a boost::system_error being thrown in this test: http://tinyurl.com/yq2yya ?
Glancing at the Boost.Test source this appears to be thrown when an internal Boost.Test assertion fails? Any ideas what's going on?
system_error is thrown in case if system level call failed. I am on vacation till the end of the week. I will try to look at this Sunday.
Thanks Gennadiy: have a good vacation! John.

Ping? Any progress on this one? Many thanks, John Maddock.
Gennadiy Rozental wrote:
John Maddock <john <at> johnmaddock.co.uk> writes:
Gennadiy,
Would you know the likely reason for a boost::system_error being thrown in this test: http://tinyurl.com/yq2yya ?
Glancing at the Boost.Test source this appears to be thrown when an internal Boost.Test assertion fails? Any ideas what's going on?
system_error is thrown in case if system level call failed. I am on vacation till the end of the week. I will try to look at this Sunday.
Thanks Gennadiy: have a good vacation!
John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

"John Maddock" <john@johnmaddock.co.uk> wrote in message news:019c01c82a95$131d4c40$e6416951@fuji...
Ping?
Would you know the likely reason for a boost::system_error being thrown in this test: http://tinyurl.com/yq2yya ?
The link now shows boost::thread_resource_error as a thrown exception. I am afraid I would have problems figuring this out even if it was boost.test exception. I need an access to the platform to debug it. The only thing I can tell immediately is that system_error is caught by execution_monitor itself (see line ~ execution_monitor.ipp:1110). So it should be some strange combination of events to produce system_error from execution monitor invocation Gennadiy

Gennadiy Rozental wrote:
The link now shows boost::thread_resource_error as a thrown exception. I am afraid I would have problems figuring this out even if it was boost.test exception. I need an access to the platform to debug it. The only thing I can tell immediately is that system_error is caught by execution_monitor itself (see line ~ execution_monitor.ipp:1110). So it should be some strange combination of events to produce system_error from execution monitor invocation
Yep, these exceptions seem to be comming and going, which is rather frustrating to say the least. Currently this one: http://tinyurl.com/3xx3o7 is showing: terminate called after throwing an instance of 'boost::system_error' EXIT STATUS: 134 So the exception is raised even before cpp_main is entered and before execution monitor's own try...catch blocks are entered I assume? Noel: I don't suppose you have a couple of spare minutes to find out where this exception is comming from? Many thanks, John Maddock.

"John Maddock" <john@johnmaddock.co.uk> wrote in message news:007f01c82db1$0a7e2680$0f8e0252@fuji...
Gennadiy Rozental wrote:
The link now shows boost::thread_resource_error as a thrown exception. I am afraid I would have problems figuring this out even if it was boost.test exception. I need an access to the platform to debug it. The only thing I can tell immediately is that system_error is caught by execution_monitor itself (see line ~ execution_monitor.ipp:1110). So it should be some strange combination of events to produce system_error from execution monitor invocation
Yep, these exceptions seem to be comming and going, which is rather frustrating to say the least. Currently this one: http://tinyurl.com/3xx3o7 is showing:
I don't believe it have something to do with Boost.Test per say.
terminate called after throwing an instance of 'boost::system_error'
EXIT STATUS: 134
So the exception is raised even before cpp_main is entered and before execution monitor's own try...catch blocks are entered I assume?
Yes. Here are all the places where syste error may've come from: execution_monitor.ipp(532): BOOST_TEST_SYS_ASSERT( ::sigaction( m_sig , sigaction_ptr(), &m_new_action ) != -1 ); execution_monitor.ipp(542): BOOST_TEST_SYS_ASSERT( sigemptyset( &m_new_action.sa_mask ) != -1 ); execution_monitor.ipp(549): BOOST_TEST_SYS_ASSERT( ::sigaction( m_sig, &m_new_action, &m_old_action ) != -1 ); execution_monitor.ipp(642): BOOST_TEST_SYS_ASSERT( ::sigaltstack( 0, &sigstk ) != -1 ); execution_monitor.ipp(648): BOOST_TEST_SYS_ASSERT( ::sigaltstack( &sigstk, 0 ) != -1 ); execution_monitor.ipp(667): BOOST_TEST_SYS_ASSERT( ::sigaltstack( &sigstk, 0 ) != -1 ); execution_monitor.ipp(696): BOOST_TEST_SYS_ASSERT( ::signal( sig, SIG_DFL ) != SIG_ERR ); What you can do is to try catch the exception in your code and report it yourself. This may at least show some information. I guess I should also include failed expression text. It's not there yet. Gennadiy

I've been getting the same problem - the following code reproduces it on an Intel mac: // Copyright 2007 Jeremy Pack // All rights reserved #define BOOST_TEST_MAIN #define BOOST_TEST_DYN_LINK 1 #include <boost/test/unit_test.hpp> #include <iostream> // #include "../src/paf_ged_loader.hpp" // #include "../src/repository.hpp" #include <boost/regex.hpp> BOOST_AUTO_TEST_CASE(regex) { boost::regex i("test"); std::string s("test"); boost::smatch match; boost::regex_match(s, match, i); } The system_error seems to be thrown at the call to regex_match. However, if I add the header #include <boost/test/execution_monitor.hpp>, the problems disappear. I've tested this in multiple files. It always dies on regex_match, unless I include boost/test/execution_monitor.hpp. Jeremy Pack On Nov 23, 2007 6:59 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:007f01c82db1$0a7e2680$0f8e0252@fuji...
Gennadiy Rozental wrote:
The link now shows boost::thread_resource_error as a thrown exception. I am afraid I would have problems figuring this out even if it was boost.test exception. I need an access to the platform to debug it. The only thing I can tell immediately is that system_error is caught by execution_monitor itself (see line ~ execution_monitor.ipp:1110). So it should be some strange combination of events to produce system_error from execution monitor invocation
Yep, these exceptions seem to be comming and going, which is rather frustrating to say the least. Currently this one: http://tinyurl.com/3xx3o7 is showing:
I don't believe it have something to do with Boost.Test per say.
terminate called after throwing an instance of 'boost::system_error'
EXIT STATUS: 134
So the exception is raised even before cpp_main is entered and before execution monitor's own try...catch blocks are entered I assume?
Yes.
Here are all the places where syste error may've come from:
execution_monitor.ipp(532): BOOST_TEST_SYS_ASSERT( ::sigaction( m_sig , sigaction_ptr(), &m_new_action ) != -1 ); execution_monitor.ipp(542): BOOST_TEST_SYS_ASSERT( sigemptyset( &m_new_action.sa_mask ) != -1 ); execution_monitor.ipp(549): BOOST_TEST_SYS_ASSERT( ::sigaction( m_sig, &m_new_action, &m_old_action ) != -1 ); execution_monitor.ipp(642): BOOST_TEST_SYS_ASSERT( ::sigaltstack( 0, &sigstk ) != -1 ); execution_monitor.ipp(648): BOOST_TEST_SYS_ASSERT( ::sigaltstack( &sigstk, 0 ) != -1 ); execution_monitor.ipp(667): BOOST_TEST_SYS_ASSERT( ::sigaltstack( &sigstk, 0 ) != -1 ); execution_monitor.ipp(696): BOOST_TEST_SYS_ASSERT( ::signal( sig, SIG_DFL ) != SIG_ERR );
What you can do is to try catch the exception in your code and report it yourself. This may at least show some information. I guess I should also include failed expression text. It's not there yet.
Gennadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

"Jeremy Pack" <rostovpack@gmail.com> wrote in message news:1b251b590711261936x48ec6594t3f2e22e7ca6d852f@mail.gmail.com...
However, if I add the header #include <boost/test/execution_monitor.hpp>, the problems disappear. I've tested this in multiple files. It always dies on regex_match, unless I include boost/test/execution_monitor.hpp.
Jeremy Pack
Could this be related to the problem I posted on 11/23/2007? When I include header <boost/test/unit_test.hpp> in my program, the linker complains that symbol "execution_exception" is undefined. I looked at the compiler output and found that class "execution_exception" is a parameter on "virtual void exception_caught(execution_exception const&)" in file test_observer.hpp. It is declared but never defined. I added "#include <boost/test/execution_monitor.hpp>" to file test_observer.hpp and the linker error went away. Is this the correct way to fix the problem?

Jeremy Pack wrote:
I've been getting the same problem - the following code reproduces it on an Intel mac:
// Copyright 2007 Jeremy Pack // All rights reserved
#define BOOST_TEST_MAIN #define BOOST_TEST_DYN_LINK 1 #include <boost/test/unit_test.hpp> #include <iostream>
// #include "../src/paf_ged_loader.hpp" // #include "../src/repository.hpp" #include <boost/regex.hpp>
BOOST_AUTO_TEST_CASE(regex) { boost::regex i("test"); std::string s("test"); boost::smatch match; boost::regex_match(s, match, i); }
The system_error seems to be thrown at the call to regex_match.
This is very strange - especially as regex makes no use of Boost.Test internally - I don't see how a call into the regex lib can result in Boost.Test throwing ! Are you able to trap the point at which the exception is thrown (gdb has an option to break on a throw exception I believe): what we really need to determine is the code that triggers this. Many thanks, John Maddock.
participants (4)
-
Dave Jenkins
-
Gennadiy Rozental
-
Jeremy Pack
-
John Maddock