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

Subject: Re: [boost] [test] Untraceable Boost.Test framework internal error: unknown reason
From: Peter Soetens (peter.soetens_at_[hidden])
Date: 2009-06-16 05:35:24

On Tue, Jun 16, 2009 at 00:24, Gennadiy Rozental <rogeeff_at_[hidden]> 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