Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 22 11:46
    risaldar closed #356
  • Oct 15 06:49
    khuang0312 edited #362
  • Oct 15 06:46
    khuang0312 edited #362
  • Oct 15 06:45
    khuang0312 edited #362
  • Oct 15 06:45
    khuang0312 opened #362
  • Oct 06 22:59
    Eazhi synchronize #361
  • Oct 06 22:55
    Eazhi synchronize #361
  • Oct 05 14:36
    utybo commented #229
  • Oct 04 00:57
    Eazhi synchronize #361
  • Oct 04 00:54
    Eazhi synchronize #361
  • Oct 04 00:44
    Eazhi opened #361
  • Oct 02 14:29
    zbeaoce opened #360
  • Oct 01 23:29
    paul000001 closed #358
  • Sep 16 19:51
    stef commented #221
  • Sep 04 21:11
    yesudeep opened #359
  • Aug 22 13:29
    paul000001 commented #358
  • Aug 15 06:37
    Snaipe closed #349
  • Aug 15 06:37
    Snaipe commented #349
  • Aug 15 06:28
    Snaipe commented #358
  • Aug 13 23:43
    paul000001 commented #358
Franklin Mathieu
@Snaipe
sure
Franklin Mathieu
@Snaipe
done in 435f41d
Franklin Mathieu
@Snaipe
I've put up a first release candidate for 2.3.0. The announcement & changelog can be found on the ml.
As always, feedback appreciated!
Ben Turrubiates
@bturrubiates
hi, i’ve run into an issue. i was having trouble getting parameterized tests to work

I took one of the examples from the samples directory:

#include <criterion/parameterized.h>
#include <stdio.h>

struct tuple {
¬       int i;
¬       int x;
};

ParameterizedTestParameters(params, simple)
{
¬       struct tuple vals[] = {
¬       ¬       {.i = 1, .x = 4},
¬       ¬       {.i = 2, .x = 5},
¬       ¬       {.i = 3, .x = 6}
¬       };

¬       size_t size = sizeof(vals) / sizeof(struct tuple);

¬       return cr_make_param_array(struct tuple, vals, size);
}

ParameterizedTest(struct tuple *val, params, simple) {
¬       cr_assert_fail("parameters: %d", val->i);
}

And this seems to be failing for me. I get:

[----] src/test.c:23: Assertion failed: parameters: 4196848
[FAIL] params::simple: (0.00s)
[----] src/test.c:23: Assertion failed: parameters: -12240
[FAIL] params::simple: (0.00s)
[----] src/test.c:23: Assertion failed: parameters: 0
[FAIL] params::simple: (0.00s)
[====] Synthesis: Tested: 3 | Passing: 0 | Failing: 3 | Crashing: 0
Franklin Mathieu
@Snaipe
@bturrubiates what happens if you make vals static? iirc the array needs to exist after the function returns
Ben Turrubiates
@bturrubiates
:clap: oh i’m an idiot, that works
Franklin Mathieu
@Snaipe
no worries :smile:
Ben Turrubiates
@bturrubiates
hmm, that wasn’t mentioned anywhere in the docs on readthedocs, i was following that and i guess i dropped the static part
could you maybe add in something to the docs that explicitly states that it needs to be static if not dynamically allocated?
Franklin Mathieu
@Snaipe
Sure
Ben Turrubiates
@bturrubiates
thanks!
Ben Turrubiates
@bturrubiates
@Snaipe Is it valid to use the assertion macros in the teardown/setup functions?
Franklin Mathieu
@Snaipe
@bturrubiates no, use cr_skip_test()
(although cr_skip_test() is only logical on a setup standpoint -- if something goes terribly wrong in initialization or finalization just call abort() and let the test crash)
Ben Turrubiates
@bturrubiates
Thanks. I upgraded to 2.3.0rc1 so I could use cr_skip_test, and I see that —pattern is now —filter and —no-early-exit is now deprecated. I used to make use of pattern and no-early-exit for inspecting leaks with valgrind. How do I accomplish that now?
Valgrind output is always clean (even though I know that this test has a memory leak)
Franklin Mathieu
@Snaipe
You just need to pass --trace-children=yes to valgrind
Ben Turrubiates
@bturrubiates
Oh, you’re awesome.
Why didn’t I need that before?
Franklin Mathieu
@Snaipe
well it seems that fork() didn't count as a "child" for valgrind
now that criterion calls exec() after fork, valgrind needs that option
Ben Turrubiates
@bturrubiates
Oh, I see now.
Franklin Mathieu
@Snaipe
also now that criterion is calling exec, your valgrind logs should be much cleaner, as the new sandboxes won't inherit the memory of the parent
Ben Turrubiates
@bturrubiates
I haven’t been tracking development on Criterion so wasn’t aware of that change.
Also, that works great. :fire: :sparkles: Thanks
Btw, I looked at the docs for master on readthedocs and didn’t see anything about cr_skip_test, is that just because that change hasn’t made it into master / a stable release yet?
Franklin Mathieu
@Snaipe
yes
the latestdocs should mirror the most current edition
once the stable 2.3.0 release is out, the stable docs will be updated automatically
Ben Turrubiates
@bturrubiates
i hadn’t even noticed that option. thanks!
so I know you mentioned abort/cr_skip_test, but if i want to mark a test as failed if something fails during setup/teardown is abort the best option (or maybe something like cr_assert_fail?)
Franklin Mathieu
@Snaipe
abort is indeed the best solution right now. cr_assert and all of its variant actually longjmp()s, and the jmp_buf isn't setup during setup or teardown
if a initialisation condition fails often, perhaps it's best to actually include it in the test itself and itest it
failures in setup/teardown should probably either mandate a skip, or remain exceptional
also if you call abort in those functions you'll still be notified with a warning that the setup or teardown crashed, which reinforces the fact that it's an exceptional condition
Ben Turrubiates
@bturrubiates
well they shouldn’t fail, i put that stuff in setup/teardown because it’s boilerplate that a whole suite will share. but sometimes it’s useful to be able to error if something in setup/teardown fails. i think it makes sense for abort to be the most obvious choice
yeah, sounds good to me. they shouldn’t fail, if they did then something has gone wrong
Franklin Mathieu
@Snaipe
right. downright exiting for these conditions makes the most sense because you're not explicitely testing that failure
Ben Turrubiates
@bturrubiates
what is the —debug option supposed to do if TYPE is not provided?
the -h output seems to indicate that it’s optional
Franklin Mathieu
@Snaipe
@bturrubiates it chooses a debugging server appropriately depending on the compiler used
gcc/icc make it use gdbserver, clang makes it use lldb-server
Ben Turrubiates
@bturrubiates
Oh, that makes sense. The system I’m working on has clang but not lldb. So I’m getting something like:
bturrubi at blade11 :: ./src/usnic-av-tests -j1 --debug
[----] Criterion v2.3.0-rc1
[====] Running 2 tests from bind_ep:
criterion: Could not spawn test instance: No such file or directory
[1]    23360 abort      ./src/usnic-av-tests -j1 --debug
Franklin Mathieu
@Snaipe
Ah, I thought I made the "No such file or directory" message a bit clearer, but I must've forgot
It should definitely print that the debugging server could not be found
Ben Turrubiates
@bturrubiates
Cool, I don’t think lldb-server works on Linux yet
Franklin Mathieu
@Snaipe
I'm on archlinux, and it works quite well on my end
Ben Turrubiates
@bturrubiates

Oh, weird. I was going off of this paragraph:

LLDB is improving on Linux. While the debugserver has not been ported (to enable remote debugging) Linux is nearing feature completeness with Darwin to debug x86_64 programs, and is partially working with i386 programs. ARM architectures on Linux are untested. For more details, see the Features by OS section below.

Found here: http://lldb.llvm.org/status.html