These are chat archives for Snaipe/Criterion

28th
Sep 2016
Ben Turrubiates
@bturrubiates
Sep 28 2016 22:52
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
Sep 28 2016 22:53
You just need to pass --trace-children=yes to valgrind
Ben Turrubiates
@bturrubiates
Sep 28 2016 22:53
Oh, you’re awesome.
Why didn’t I need that before?
Franklin Mathieu
@Snaipe
Sep 28 2016 22:54
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
Sep 28 2016 22:55
Oh, I see now.
Franklin Mathieu
@Snaipe
Sep 28 2016 22:55
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
Sep 28 2016 22:55
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
Sep 28 2016 22:56
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
Sep 28 2016 22:57
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
Sep 28 2016 23:01
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
Sep 28 2016 23:04
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
Sep 28 2016 23:05
right. downright exiting for these conditions makes the most sense because you're not explicitely testing that failure