#3664 closed Bugs (fixed)
SIGCHLD always considered fatal error
Reported by: | Johan Nilsson <r DOT johan DOT nilsson AT gmail DOT com> | Owned by: | Gennadiy Rozental |
---|---|---|---|
Milestone: | Boost 1.59.0 | Component: | test |
Version: | Boost 1.40.0 | Severity: | Problem |
Keywords: | Cc: |
Description
Under *nix platforms, unless system error handling is disabled using e.g. "BOOST_TEST_CATCH_SYSTEM_ERRORS=no" in the environment, an exiting child process is always considered a fatal error, no matter what the reason for the child's exit is.
Currently, the only way to disable this behaviour without simultaneously disable the handling of all system events is to recompile the library with the BOOST_TEST_IGNORE_SIGCHLD preprocessor macro defined. This makes it impossible to write tests that starts/stops child processes and attempts to inspect their exit codes using the vanilla build of Boost.Test.
I suggest that the handling of SIGCHLD should be possible to enable/disable in the same way as the other run-time parameters, with a default value that disables handling of SIGCHLD (which is run-time compatible with older Boost releases).
Some applicable references:
http://thread.gmane.org/gmane.comp.lib.boost.user/40172 http://thread.gmane.org/gmane.comp.lib.boost.user/46504 http://thread.gmane.org/gmane.comp.lib.boost.user/52991
Change History (3)
follow-up: 2 comment:1 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 11 years ago
Replying to rogeeff:
(In [57995]) Avoid catching SIGCHILD altogether. One should exanine system call exit code instead. Fixes #3664
This fix does not appear to have been included in the trunk yet. Is this an oversight, or is there a reason this has not been included? I'm happy to work on providing a unit test for this if necessary, since this affects my current project...
Dave
comment:3 by , 7 years ago
Milestone: | Boost 1.42.0 → Boost 1.59.0 |
---|
(In [57995]) Avoid catching SIGCHILD altogether. One should exanine system call exit code instead. Fixes #3664