Yeah, so here is an example:
#include <unistd.h>
#include <criterion/criterion.h>
Test(fork_test, fork_fail) {
pid_t pid = fork();
}
and here is the failure:
Assertion failed: !self->paused (/tmp/tmp.ZlO8JlxD9T/criterion/dependencies/nanomsg-patched/src/aio/worker_posix.inc:202)
[----] test.c:5: Unexpected signal caught below this line!
[FAIL] fork_test::fork_fail: CRASH!
[====] Synthesis: Tested: 1 | Passing: 0 | Failing: 1 | Crashing: 1
I was previously using the 2.2.1 tag and it was crashing somewhere in setup but I switched to bleeding and this is the new error I’m getting. It only seems to happen if the fork is in the code.
I'm not surprised that bleeding isn't working with forks considering that fork support in nanomsg is still a WIP. I am however more surprised that this isn't working with 2.2.1, do you have more details?
I don’t, I have a 2.2.1 build on another machine. Give me a sec and I can get that for you.
[ERR ] Could not link back the event PID to the active workers.
[ERR ] The event pipe might have been corrupted.
bturrubi at savbu-usnic-a :: ./a.out --verbose /tmp/tmp.7ajmSZTkOA
[----] Criterion v2.2.1
[====] Running 1 test from fork_test:
[RUN ] fork_test::fork_fail
[PASS] fork_test::fork_fail: (0.00s)
[ERR ] Could not link back the event PID to the active workers.
[ERR ] The event pipe might have been corrupted.
My guess is that you need to explicitely call exit in the child you spawn
Oh, how embarrassing :blush: that does seem to fix it for the simple example. :clap:
cr_assert_not_null
calls then it finishes just fine. I tested those pointers explicitly with an if gaurd and they’re not NULL
and I can access things stored in them just fine. I’m not sure I know what’s special about those structs.
cr_assert
them either. These are just struct pointers btw.
valgrind
then some of the asserts fail and it complains that I’m using shared memory. The struct pointer that is problematic is not related to the shared memory segment at all, but if I comment out the cr_assert_not_null
and just change it to an if
, then the test passes successfully.
#include <unistd.h>
#include <stdlib.h>
#include <criterion/criterion.h>
Test(fork_test, fork_fail) {
pid_t pid = fork();
if (pid == 0) {
cr_assert_eq(0, 0, "fail");
exit(0);
}
}
[----] Criterion v2.2.1
[====] Running 1 test from fork_test:
[RUN ] fork_test::fork_fail
[PASS] fork_test::fork_fail: (0.00s)
[ERR ] Could not link back the event PID to the active workers.
[ERR ] The event pipe might have been corrupted.
Aborted (core dumped)
Ah, right on! This is indeed not supported at all at the moment because duplicating the pipe is nontrivial at this point
OH, fair enough. Didn’t know that.
but I'm afraid this will be a wontfix for 2.2.x -- you'll have to use some kind of synchronization mechanism in the meantime
What am I synchronizing access to?
yeah, this is quite the pain to setup, you might be better off not using the framework in the meantime if you're spawning new processes
I’ll probably just do that. I don’t find myself in this situation often.