On Thu, 05 Nov 2009 09:06:16 +0100, Johan Nilsson wrote:

[...]

...

You can define BOOST_TEST_IGNORE_NON_ZERO_CHILD_CODE or BOOST_TEST_IGNORE_SIGCHLD for Boost.Test which as far as I remember must be rebuilt then. :-/

Thanks for the pointer. I was hoping for a provided run-time solution, which would have been the best.

Yes, I agree.

If stuck with a compile-time solution, it would IMHO have been more lenient having to define e.g. BOOST_TEST_HANDLE_NON_ZERO_CHILD_CODE and BOOST_TEST_HANDLE_SIGCHLD rather than having this new behaviour by default. I really can't currently imagine a scenario where I would want this enabled.

It's the execution monitor in file /boost/test/impl/execution_monitor.ipp which registers the signal handlers. The execution monitor has a public property called p_catch_system_errors which (according to http://www.boost.org/doc/libs/1_40_0/libs/test/doc/html/execution-monitor/us...) can be set to false to suppress registering any signal handler. It's all or nothing but there seems to be a way. Boris

Gennadiy Rozental wrote:

Boris Schaeling writes:

...

...

Thanks for the pointer. I was hoping for a provided run-time solution, which would have been the best.

Yes, I agree.

If nothing else works, you can reset signal handler yourself inside the test case.

...

...

If stuck with a compile-time solution, it would IMHO have been more lenient having to define e.g. BOOST_TEST_HANDLE_NON_ZERO_CHILD_CODE and BOOST_TEST_HANDLE_SIGCHLD rather than having this new behaviour by default. I really can't currently imagine a scenario where I would want this enabled.

Boost.Test is trying to catch all kinds of failures. Child proces crashing or returning non-zero error code is usual indication of an error.

I'm not convinced. As for signalling a crashing child process (if it can be detected) as a fatal error, yes. As for treating a non-zero "error" code from the result of executing a child process as a fatal error, no (IIUC it is not an error code, it is a status/exit code that _could_ indicate an error or simply a non-positive result). As an example, the "ls" program uses a non-zero status code to indicate that the searched for files were not found. Is this a fatal error - I don't think so. It's an analogy to the C++ debate on whether to use status codes vs using exceptions. If you are still not convinced, would it then be possible for you to add a supported mechanism to selectively disable/enable the interpretations of such events as fatal errors or not? BOOST_TEST_CATCH_SYSTEM_ERRORS is just too coarse a mechanism. As a side note: I've been searching the archives for the boost developers/users list and found no posts where the users where complaining about _not_ having SIGCHLD handled. I have though found a couple of ones where people have been complaining about the opposite since the introduction of the feature. Best regards, Johan