These are chat archives for Snaipe/Criterion

28th
Jun 2016
Sign in to start talking
Franklin Mathieu
@Snaipe
Jun 28 2016 04:16
@bturrubiates it should work, although it's untested right now. Are you having troubles with it?
Ben Turrubiates
@bturrubiates
Jun 28 2016 04:40

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.

My other test suite works perfectly fine on this build of Criterion, but it doesn’t have any forks in it.
Franklin Mathieu
@Snaipe
Jun 28 2016 05:46
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?
Franklin Mathieu
@Snaipe
Jun 28 2016 05:54
Also, thank you for the log, I'll fix the fork patch to support successive calls
Ben Turrubiates
@bturrubiates
Jun 28 2016 05:56

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.
Same example.
Ben Turrubiates
@bturrubiates
Jun 28 2016 06:02
Oh actually, this example doesn’t crash like my other one did: 
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.
Franklin Mathieu
@Snaipe
Jun 28 2016 06:05
My guess is that you need to explicitely call exit in the child you spawn
I'll add some support code in criterion to compare the PID and just exit if it's a child
Ben Turrubiates
@bturrubiates
Jun 28 2016 06:08

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:

Ben Turrubiates
@bturrubiates
Jun 28 2016 06:26
My actual test is still bugging out, but it isn’t clear to me whether it’s Criterion or my test.
Ben Turrubiates
@bturrubiates
Jun 28 2016 07:03
This is going to sound weird, but if I remove a couple of 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.
I also can’t cr_assert them either. These are just struct pointers btw.
Unfortunately I don’t have any useful debug output to give you. If I try to run it through 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.
Ben Turrubiates
@bturrubiates
Jun 28 2016 07:10
Anyways, thanks @Snaipe for the heads up about calling exit in the tests. In retrospect that should have been obvious :+1:. It’s late here, goodnight.
Franklin Mathieu
@Snaipe
Jun 28 2016 12:45
I'm not completely getting the issue with cr_assert_not_null -- when you get the time, could you send me maybe a snippet/some logs?
Ben Turrubiates
@bturrubiates
Jun 28 2016 15:20
Oh I see what’s going on, I can call fork but I can’t use any of the assertion functionality from the child. 
#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)
Franklin Mathieu
@Snaipe
Jun 28 2016 15:22
Ah, right on! This is indeed not supported at all at the moment because duplicating the pipe is nontrivial at this point
it might be possible in the near future on bleeding once the fork patch is stable
Ben Turrubiates
@bturrubiates
Jun 28 2016 15:23

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.

Franklin Mathieu
@Snaipe
Jun 28 2016 15:24
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
Ben Turrubiates
@bturrubiates
Jun 28 2016 15:24
Cool, I’ll look forward to using the feature on bleeding once it’s stable. :+1:

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?

Franklin Mathieu
@Snaipe
Jun 28 2016 15:26
I mean use some kind of reporting mechanism from the child to the parent and make them wait at specific rendez-vous points to have coherent assertion data
so, in effect:
  1. open a pipe
  2. fork()
  3. a. in the child, test the condition and write the result in the pipe
    b. in the parent, read the result from the pipe and call cr_assert
    and repeat until done
Ben Turrubiates
@bturrubiates
Jun 28 2016 15:28
Oh okay, I could do that until the functionality is available. I actually just ended up re-writing the set of tests I had without a testing framework.
Franklin Mathieu
@Snaipe
Jun 28 2016 15:30
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
Ben Turrubiates
@bturrubiates
Jun 28 2016 15:31

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.

Thanks