Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 14 16:25
    Snaipe commented #301
  • Sep 13 19:26
    Snaipe commented #302
  • Sep 13 19:21
    Snaipe commented #302
  • Sep 13 17:36
    MrAnno commented #301
  • Sep 13 17:35
    MrAnno commented #301
  • Sep 13 15:28
    kugel- commented #302
  • Sep 13 15:26
    kugel- commented #302
  • Sep 13 15:14
    Snaipe labeled #302
  • Sep 13 15:14
    Snaipe labeled #302
  • Sep 13 15:14
    Snaipe labeled #302
  • Sep 13 15:14
    Snaipe assigned #302
  • Sep 13 15:14
    Snaipe opened #302
  • Sep 13 14:55

    Snaipe on actions

    ci: setup basic actions yaml (compare)

  • Sep 11 08:33
    MrAnno opened #301
  • Sep 03 18:13
    Fumesover closed #300
  • Sep 03 18:13
    Fumesover commented #300
  • Sep 03 18:02
    Fumesover edited #300
  • Sep 03 18:02
    Fumesover edited #300
  • Sep 03 17:32
    Fumesover opened #300
  • Aug 26 18:59
    4lph4-Ph4un closed #298
Franklin Mathieu
@Snaipe
That might just as well become a mantra, in the case of C :P
Dominik
@kaidowei
unfortunately, yes
well, time to go home xD
Franklin Mathieu
@Snaipe
Have a nice day
Dominik
@kaidowei
ditto
Ben Turrubiates
@bturrubiates
Hi
So question for @Snaipe or anyone: is Criterion supposed to be able to handle a call to fork() inside one of the tests?
Franklin Mathieu
@Snaipe
@bturrubiates it should work, although it's untested right now. Are you having troubles with it?
Ben Turrubiates
@bturrubiates

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
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
Also, thank you for the log, I'll fix the fork patch to support successive calls
Ben Turrubiates
@bturrubiates

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
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
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

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
My actual test is still bugging out, but it isn’t clear to me whether it’s Criterion or my test.
Ben Turrubiates
@bturrubiates
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
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
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
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
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

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
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
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
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
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
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

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
Douman
@DoumanAsh
Hi, wanted to let you know: there is small issue with github releases. When it generates code tarball submodules are not initialized so there is no way to use release sources to build criterion. github's support told me that they take note of that but no promises if they're going to fix it. So... anyway letting you know cuz i stumbled on that myself :)
Franklin Mathieu
@Snaipe
@DoumanAsh Right, you're actually the 2nd person this week to notify me of this issue, I'll add a bundled archive for this case. :)
Douman
@DoumanAsh
That would be cool :)
Btw have been playing with mimick in my work environment... Kinda made it wok by moving from static libs to dynamic libs. But what is strange that even though mimick is able to stub function without a problem, the stub is not called at all :( I know this is WIP but do you have any advices @Snaipe ?
Franklin Mathieu
@Snaipe
There are multiple factors in play here, so, in order:
  1. what platform (os + arch) are you on?
Douman
@DoumanAsh
linux; 64bit;
Franklin Mathieu
@Snaipe
\2. what libc are you using? (glibc or eglibc?)
Douman
@DoumanAsh
glibc
Franklin Mathieu
@Snaipe
okay, what are you doing when calling mmk_mock? (i.e. what line are you using?)
Douman
@DoumanAsh
i'm actually creating stub, not mock