Boost logo

Boost :

From: Martin Wille (mw8329_at_[hidden])
Date: 2003-10-30 05:29:58


Gennadiy Rozental wrote:
> Hi,
> I have some problem with gcc that came with cygwin. I remember it was
> reported before either. error_handling_test hangs during run.

I found a (probably) related problem when using como (on Linux)
with Boost.Test.

This code results in an infinite loop, too, when using como.

#include <iostream>
#include <boost/test/included/unit_test_framework.hpp>

struct foo
     ~foo() { std::cout << "~foo\n"; }

     foo bar;

init_unit_test_suite(int argc, char* argv[])
     boost::unit_test_framework::test_suite* test
         = BOOST_TEST_SUITE("unit test signal handling test");


     return test;

(This is from what I sent to Comeau Computing regarding
that problem:)

"The binary created by como throws SIG_ABORT as consequence
of std::terminate(). The signal handler is invoked and
siglongjmp()s back to the main program. I suspect the
exception handling environment gets screwed at that
point. The Boost.Test library throws an exception
as response to the siglongjmp(). The handler for
the exception isn't found. std::terminate() is called
due to unhandled_exception(). The signal handler
is called again ..."

By (sig)longjump()ing out of a signal handler we're in
UB land, I think. The state of objects on the stack
is undefined, according to the standard, when a long-
jmp causes a jump back over stack frames.

GCC and ICC on Linux seem to handle the the problem
nicely, while como doesn't seem to get the exception
handling "right". I guess the same happens with gcc
on Windows.

One (ugly but working) solution would be to disable
sigaction based signal handling for the affected


Boost list run by bdawes at, gregod at, cpdaniel at, john at