These are chat archives for Snaipe/Criterion

3rd
Mar 2016
Dominik
@kaidowei
Mar 03 2016 17:30
@Snaipe are you interested in memory leaks for criterion v2.2.0?
Franklin Mathieu
@Snaipe
Mar 03 2016 17:30
sure, what do you have ?
Dominik
@kaidowei
Mar 03 2016 17:31
{
   criterion redirect pipe
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   fun:fdopen@@GLIBC_2.2.5
   fun:pipe_in
   fun:cr_get_redirected_*
}
Franklin Mathieu
@Snaipe
Mar 03 2016 17:32
where is this happenning?
Dominik
@kaidowei
Mar 03 2016 17:32
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   fun:alloc_entry
   fun:smalloc_impl
   fun:smalloc
   fun:test_stats_init
   fun:run_next_test
   fun:run_tests_async
   fun:criterion_run_all_tests_impl
   fun:criterion_run_all_tests
   fun:main
}
Franklin Mathieu
@Snaipe
Mar 03 2016 17:32
oh, wait, it's a suppression
Dominik
@kaidowei
Mar 03 2016 17:32
yeah
I can send you the stacktrace/code too
Franklin Mathieu
@Snaipe
Mar 03 2016 17:33
I would rather, cr_get_redirected_* isn't really helpful
I think the second leak has been fixed on patch
Dominik
@kaidowei
Mar 03 2016 17:34
==743== 568 bytes in 1 blocks are still reachable in loss record 2 of 2
==743==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==743==    by 0x50C2D41: fdopen@@GLIBC_2.2.5 (iofdopen.c:138)
==743==    by 0x4E42713: pipe_in (pipe.c:46)
==743==    by 0x4E43B00: cr_get_redirected_stderr (redirect.c:62)
==743==    by 0x401FDA: another_suite_test_stdout_impl (test_all.c:44)
==743==    by 0x4E425C5: criterion_internal_test_main (test.c:56)
==743==    by 0x4016EA: another_suite_test_stdout_jmp (test_all.c:37)
==743==    by 0x4E3F6F8: run_test_child (runner.c:180)
==743==    by 0x4E41808: run_worker (worker.c:84)
==743==    by 0x4E4193C: spawn_test_worker (worker.c:111)
==743==    by 0x4E40FCE: run_test (runner_coroutine.c:66)
==743==    by 0x4E41506: run_next_test (runner_coroutine.c:162)
==743== 
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   fun:fdopen@@GLIBC_2.2.5
   fun:pipe_in
   fun:cr_get_redirected_stderr
   fun:another_suite_test_stdout_impl
   fun:criterion_internal_test_main
   fun:another_suite_test_stdout_jmp
   fun:run_test_child
   fun:run_worker
   fun:spawn_test_worker
   fun:run_test
   fun:run_next_test
}
arg
Franklin Mathieu
@Snaipe
Mar 03 2016 17:34
oh, right
Dominik
@kaidowei
Mar 03 2016 17:34
static void redirect_all_std(void) {
    cr_redirect_stdout();
    cr_redirect_stderr();
}

Test(another_suite, test_stdout, .init = redirect_all_std) {
    fprintf(stdout, "foo");
    fflush(stdout);
    cr_assert_stdout_eq_str("foo");

    fprintf(stderr, "bar");
    fflush(stderr);
    cr_assert_stderr_eq_str("bar");
}
and the other one....
Franklin Mathieu
@Snaipe
Mar 03 2016 17:36
I think I forgot to close both file handles, so it's (kinda) normal
and yeah, 2nd memleak has been fixed on bleeding
Dominik
@kaidowei
Mar 03 2016 17:37
ah okay. But I guess we will not switch to bleeding :D
Franklin Mathieu
@Snaipe
Mar 03 2016 17:38
yeah, not yet though
I'll cherry pick the fix on the patch branch
Dominik
@kaidowei
Mar 03 2016 17:38
thanks
plans for 2.2.1?
Franklin Mathieu
@Snaipe
Mar 03 2016 17:39
2.2.1 will be released this saturday if everything goes right
Franklin Mathieu
@Snaipe
Mar 03 2016 22:10
@kaidowei I experimented a bit more with the 1rst API draft and came up with this: http://pastebin.com/raw/dkCKD4YY
This possible 2nd draft should be more adequate than the first for mocking
(the syntax is inspired by mockito)
I haven't got the time to really make a full implementation, but it seems to be possible from the few tests I ran
I am also hesitating on the syntax of mmk_when

there's

mmk_when (malloc, m,
            .with_size = mmk_eq(size_t, sizeof (ref)),
            .then_return = buf);

of course, but

mmk_when (m, malloc(sizeof (ref)), .then_return = buf);

seems really attractive

The biggest obstacle against syntax 2 are sequence points
Franklin Mathieu
@Snaipe
Mar 03 2016 22:16
but I think I might be able to bypass it with some macro magic and __COUNTER__.
this also opens the door to over the top control over parameter conditions
because then you could have easily something like:
mmk_when (m, foo(1, mmk_lt(0), mmk_arg_that(is_valid)), .then_return = 42);
and specify whatever matcher you want