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