Re: [boost] error_handling_test hungs

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

Hi,

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.

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

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

void
raise_a_signal()
{
     foo bar;
     std::terminate();
}

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

     test->add(BOOST_TEST_CASE(&raise_a_signal));

     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
compilers.

HTH,
m