Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 23 16:53
    rmzelnick commented #309
  • Oct 23 16:53
    rmzelnick commented #309
  • Oct 23 14:46
    Snaipe commented #309
  • Oct 23 13:17
    rmzelnick commented #309
  • Oct 23 11:54
    Snaipe commented #309
  • Oct 23 02:46
    rmzelnick commented #309
  • Oct 23 02:44
    rmzelnick commented #309
  • Oct 23 02:36
    rmzelnick commented #309
  • Oct 23 02:36
    rmzelnick commented #309
  • Oct 23 02:28
    rmzelnick commented #309
  • Oct 23 02:25
    rmzelnick commented #309
  • Oct 23 02:24
    rmzelnick commented #309
  • Oct 23 02:08
    rmzelnick reopened #309
  • Oct 23 02:08
    rmzelnick commented #309
  • Oct 23 02:08
    rmzelnick closed #309
  • Oct 23 02:08
    rmzelnick commented #309
  • Oct 23 02:01
    rmzelnick commented #309
  • Oct 23 01:51
    rmzelnick commented #309
  • Oct 22 10:11
    am11 commented #309
  • Oct 22 09:48
    Snaipe commented #309
Ben Turrubiates
@bturrubiates
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
Franklin Mathieu
@Snaipe
ah, well, same question for mmk_stub then
Douman
@DoumanAsh
oh let me remember...
Franklin Mathieu
@Snaipe
the things that can come to mind here at this point are either overzealous compiler optimisation or wrong selector usage
Douman
@DoumanAsh
well i created just stub: mmk_stub_create("sctphost@self", sctphost_stub, 0) - i tried different selectors: lib:<dynamic_lib_with_symbol> and sym:sctphost
after i converted my lib from static to dynamic it started to return ok
but still no luck.
i tried to turn off all optimizations
and no luck too :(
Franklin Mathieu
@Snaipe
assuming that sctphost doesn't have any fancy optimisation attribute such as __attribute__((pure)) it shouldn't be optimized away, so mimick might not be able to find the dynamic symbol