Re: [boost] [test] Untraceable Boost.Test framework internal error: unknown reason

16 Jun 2009

      On Tue, Jun 16, 2009 at 00:24, Gennadiy Rozental <rogeeff@gmail.com> wrote:
...
Peter Soetens <peter.soetens <at> gmail.com> writes:
...
Hi,
I'm using Boost 1.37.0 (Ubuntu Jaunty). When I run my testcases, they
seem to complete well, but just before the end of the program exit, I
get this error from Boost UTF:
Please show simple example.
It's no simple case since I only get this when I use the Xenomai real-time
kernel.

The point is that maybe Xenomai or the kernel is signalling my process, and
that
due to the (numerous) catch(...) statements in Boost.Test, these are caught
by
the library and not by my debugger. The exception may be thrown during the
cleanup
of a global fixture, in this code:

struct InitOrocos {
public:
    InitOrocos(){  }
    ~InitOrocos(){ __os_exit(); } // probably the cause of the exception (?)

};

BOOST_GLOBAL_FIXTURE( InitOrocos )

boost::unit_test::test_suite* init_unit_test_suite(int argc, char** argv)
{
    __os_init(argc, argv);

    // disable logging of errors or warnings if no ORO_LOGLEVEL was set.
    if ( log().getLogLevel() == Logger::Warning ) {
        log(Info) << "Lowering LogLevel to Critical." << endlog();
        log().setLogLevel(Logger::Critical);
    } else {
        log(Info) << "LogLevel unaltered by test-runner." << endlog();
    }

    // manually adding test suites
    test_suite* test = BOOST_TEST_SUITE("Name of test suite");

    return test;
}
...
What compiler are you using?
GCC 4.3.3 (Ubuntu Jaunty)
...
Did you try latest boost?
No, but I'd be really pleased if I had it working with 1.37, which is today
common
with Linux distributions. I'll try 1.39 as well.
...
...
Boost.Test framework internal error: unknown reason
FATAL: exception not rethrown
Aborted
I spent an hour trying to figure out 1) how to find out where the
exception was thrown and 2) if the exception catching in boost could
be disabled such that a simple gdb backtrace could point
me to it.
I have the suspicion that one of the signal handlers that boost UTF
installs gets triggered, but I also did not find any way to disable
the boost signal handlers.
I doubt Boost.Test handlers are the issue. You would get more
meaningful error message in that case. But you can disable them
with --catch_system_errors=no
This flag has no effect whatsoever.

Peter