[test] Still SIGCHLD issues?

[Johan Nilsson-4]

Hi,

I'm in progress of updating some projects to use Boost 1.40 (upgrading from
1.34.1).

Everything now works fine under Windows, but under Linux there are issues
with running unit tests that spawns and control child processes. My tests
now report fatal errors and stops responding. Searching the archives I see
several references to a problem with SIGCHLD, but no fix seems to have been
issued.

I'm sure there is a valid reason for treating SIGCHLD as errors, but does it
really need to be enabled by default? Seems like a regression to me.

Is it possible to disable this without patching Boost.Test? I'd really,
really, really like to not go that route.

Regards / Johan


_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boris Schaeling]

On Wed, 04 Nov 2009 13:55:18 +0100, Johan Nilsson  
<r.johan.nilsson@...> wrote:

> Hi,
>
> I'm in progress of updating some projects to use Boost 1.40 (upgrading  
> from 1.34.1).
>
> Everything now works fine under Windows, but under Linux there are  
> issues with running unit tests that spawns and control child processes.  
> My tests now report fatal errors and stops responding. Searching the  
> archives I see several references to a problem with SIGCHLD, but no fix  
> seems to have been issued.
> [...]

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. :-/

Boris

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Johan Nilsson-4]

Boris Schaeling wrote:

> On Wed, 04 Nov 2009 13:55:18 +0100, Johan Nilsson
> <r.johan.nilsson@...> wrote:
>
>> Hi,
>>
>> I'm in progress of updating some projects to use Boost 1.40
>> (upgrading from 1.34.1).
>>
>> Everything now works fine under Windows, but under Linux there are
>> issues with running unit tests that spawns and control child
>> processes. My tests now report fatal errors and stops responding.
>> Searching the archives I see several references to a problem with
>> SIGCHLD, but no fix seems to have been issued.
>> [...]
>
> 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.

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.

Also, if I would want this enabled I definitely would want to have some
control over the behaviour. Is it possible to somehow handle/catch these
fatal errors explicitly in my code? I guess I could explicitly override the
SIGCHLD stuff when running under Linux, but it would be nice not having to
add more platform-specific code.



/ Johan


_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boris Schaeling]

On Thu, 05 Nov 2009 09:06:16 +0100, Johan Nilsson  
<r.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/user-guide.html)  
can be set to false to suppress registering any signal handler. It's all  
or nothing but there seems to be a way.

Boris

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Gennadiy Rozental-2]

Boris Schaeling <boris <at> highscore.de> 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.

Gennadiy.

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Johan Nilsson-4]

Gennadiy Rozental wrote:

> Boris Schaeling <boris <at> highscore.de> 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


_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users