How to cancel "fatal error" detection in BOOST TEST

Question

I get an error: unknown location(0): fatal error in "suite_1_test_1": child has exited; pid: 5817; uid: 0; exit value: 255

Inside suite_1_test_1 I run a program A with execvp() (after fork()), which may be exit with an error code that is not 0. this error code indicates what happened to program A.

The problem is that, if I get this fatal error, I can't handle the exit() value, and the BOOST TEST gets out immediately.

Can I somehow turn it off for a moment?

Thanks

Do you mean by that "How to find and fix an unknown yet bug?"? — Alexey Frunze, Apr 18 '13 at 12:48
No, I mean "How to shut down fatal error detection" or something like that... — hudac, Apr 18 '13 at 12:52
Linux, RedHat, Why does it matter? I wanted ask if there is some command in the BOOST TEST code which let me do that — hudac, Apr 18 '13 at 12:56
I care about the tests results, but I want to handle them my own way, and that is - without getting out of the test_case... just by declaring an error — hudac, Apr 18 '13 at 13:02

score 2 · Accepted Answer · edited May 23 '17 at 12:14

2

Well, it is possible to do so:

boost::unit_test case fails because a child process exits with nonzero

just do #define BOOST_TEST_IGNORE_NON_ZERO_CHILD_CODE before the #define BOOST_TEST_MODULE aot_test_module in the main()

When using shared libraries, run with command line option --catch_system_errors=no or export BOOST_TEST_CATCH_SYSTEM_ERRORS=“no”.

edited May 23 '17 at 12:14

Community

1
1

answered Apr 21 '13 at 13:00

hudac

2,584
6
34
57

Arne Mertz · Answer 2 · 2013-04-18T13:48:58.207

It seems that boost registers signal handlers or other stuff, that still catch errors from the forked (and overridden) process. You will have a hard time "unhooking" the test framework from that child process.

However, unit test frameworks are seldom meant to be used together with the spawning of child processes, so I would just not use fork and exec* inside Boost.Test. Factor these calls out of the units you are testing. After all, a process is not a signle unit, it's more a whole component. I guess you will not have many of those subprocesses, so it should not hurt too much to test the collaboration of those processes with another framework or just a simple script.

means "maybe with an unbearable amount of work and deep understanding off Boost.Test's internals". Ok, that's probably a "no" for most people, including me ;) — Arne Mertz, Apr 18 '13 at 13:48

score 0 · Answer 3 · answered Apr 18 '13 at 13:03

0

As I understand execvp() replaces your test program. So Boost.Test is not runing any longer. It only returns in case of failour. I would not use it in this context with Boost.Test.

answered Apr 18 '13 at 13:03

Jan Herrmann

2,717
17
21

I `fork()` before, sorry for not mentioning it – hudac Apr 18 '13 at 13:04

How to cancel "fatal error" detection in BOOST TEST

3 Answers3