Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 30 22:16
    kugel- commented #347
  • Mar 24 11:56
    lgutter commented #345
  • Mar 23 23:46
    kugel- opened #347
  • Mar 22 21:25
    kugel- commented #345
  • Mar 22 15:30
    Snaipe commented #345
  • Mar 22 15:30
    Snaipe commented #345
  • Mar 22 14:33
    kugel- commented #345
  • Mar 22 13:55
    Snaipe commented #345
  • Mar 21 16:49
    Snaipe commented #345
  • Mar 21 15:28
    Snaipe commented #345
  • Mar 21 15:13
    Snaipe edited #321
  • Mar 18 21:28
    kugel- commented #345
  • Mar 17 17:32
    laikq closed #346
  • Mar 17 17:32
    laikq commented #346
  • Mar 17 13:24
    kugel- commented #345
  • Mar 17 12:06
    laikq opened #346
  • Mar 17 08:35
    kugel- commented #303
  • Mar 17 08:34
    kugel- commented #303
  • Mar 12 17:39
    nloomans commented #321
  • Mar 10 18:13
    lgutter commented #345
Dominik
@kaidowei
the compiler will see some return foo for a return void function and complain
Dominik
@kaidowei
@Snaipe are you interested in memory leaks for criterion v2.2.0?
Franklin Mathieu
@Snaipe
sure, what do you have ?
Dominik
@kaidowei
{
   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
where is this happenning?
Dominik
@kaidowei
{
   <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
oh, wait, it's a suppression
Dominik
@kaidowei
yeah
I can send you the stacktrace/code too
Franklin Mathieu
@Snaipe
I would rather, cr_get_redirected_* isn't really helpful
I think the second leak has been fixed on patch
Dominik
@kaidowei
==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
oh, right
Dominik
@kaidowei
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
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
ah okay. But I guess we will not switch to bleeding :D
Franklin Mathieu
@Snaipe
yeah, not yet though
I'll cherry pick the fix on the patch branch
Dominik
@kaidowei
thanks
plans for 2.2.1?
Franklin Mathieu
@Snaipe
2.2.1 will be released this saturday if everything goes right
Franklin Mathieu
@Snaipe
@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
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
Dominik
@kaidowei
hi
just to be clear: mmk_when adds a call and verify checks, if that call was made?
Franklin Mathieu
@Snaipe
mmk_when binds a combination of parameters to a return value, mmk_verify checks whenever a function was called or not
Dominik
@kaidowei
so when I have a function that calls my mock 10 times, I have to write mmk_verify 10 times?
can't you verify in the stub?
Franklin Mathieu
@Snaipe
@kaidowei you would do mmk_verify(..., .times = 10)
mmk_verify lets you check the number of times a function has been called based on predicates
Dominik
@kaidowei
okay, I see. But why do I have to pass the same information again? Cant the mock do that work?
Franklin Mathieu
@Snaipe
What do you mean by same information?
Are you talking about mmk_when vs mmk_verify?
Dominik
@kaidowei
yes. mmk_when tells the mock how often and how it will be called;
mmk_verify should only check whether the mock really was called that way
Franklin Mathieu
@Snaipe
Actually, it's a bit more subtle than that. mmk_when defines the behaviour of the mock regardless of the number of times the stub is called. If you define foo(1) to return 1, then it will always do so.
mmk_verify asserts that at some point the function has been called with matching parameters a certain number of times
Both are complementary but not necessary to each other
If you want to test what happens when a function returns a specific value, you use mmk_when (i.e. you tell a function to do things)
If you want to test how the function has been used (i.e. you ask the function if it has been called the way you want), then you use mmk_verify