by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 29 16:53
    LeandreBl edited #353
  • May 29 16:53
    LeandreBl edited #353
  • May 29 16:51
    LeandreBl opened #353
  • May 29 15:32
    LeandreBl edited #352
  • May 29 15:32
    LeandreBl edited #352
  • May 29 15:27
    LeandreBl opened #352
  • May 29 14:54
    LeandreBl commented #351
  • May 29 14:28
    LeandreBl commented #351
  • May 29 14:28
    LeandreBl synchronize #351
  • May 29 14:26
    LeandreBl commented #351
  • May 29 13:22
    LeandreBl synchronize #351
  • May 29 13:13
    LeandreBl synchronize #351
  • May 29 12:43
    LeandreBl commented #351
  • May 29 12:31
    LeandreBl synchronize #351
  • May 29 12:25
    LeandreBl commented #351
  • May 29 12:24
    LeandreBl commented #351
  • May 29 12:22
    LeandreBl opened #351
  • May 29 12:05
    LeandreBl commented #314
  • May 29 12:03
    LeandreBl commented #314
  • May 29 11:51
    LeandreBl commented #314
Franklin Mathieu
@Snaipe
I've not even seen this in production tests
Dominik
@kaidowei
but with this approach you have a mock for every test. if my first test needs the first call to check for 42 and the second for 13, I have to define two mocks for the same function
yes, I still have to fill in the values for all functions, that get called, but I'd like to avoid writing mmk_declare for every function
Franklin Mathieu
@Snaipe
You don't have mmk_declare, that's the thing
in terms of line, it's about the same to be honest, you still have to do it somewhere
whenever it's inside a function or your test isn't that much important
Dominik
@kaidowei
yes, the generate thing was meant for the current approach
Franklin Mathieu
@Snaipe
the big plus here is that this API is lightweight, and you don't need to do some massive hacking with offsets to compare actual and expected values
you simply pass a predicate that references the parameters
Dominik
@kaidowei
I guess, we could make both work together
Franklin Mathieu
@Snaipe
that could be counterproductive
Dominik
@kaidowei
well, both have limitations
the second works for ... functions
Franklin Mathieu
@Snaipe
right, variadics work out of the box here
however the handling of void-returning functions is moved to mmk_expect
since mmk_expect takes in a hard value to return
you'd need to have a mmk_expect and mmk_expect_and_return
or something of that flavor
I guess, to be fair, that there could be some convenience functions of the sort for the stub API rather than the mock API
you could also decouple the return value from mmk_expect
Franklin Mathieu
@Snaipe
which means you'd have
static void *realloc_mock(void *ptr, size_t size) {
    mmk_mock_start;
    mmk_expect(ptr == NULL && size == 42);
    mmk_return(NULL);
    mmk_expect(ptr == (void*) -1);
    mmk_return(NULL);
    for (size_t i = 0; i < 10; ++i) {
        mmk_expect(size == i);
        mmk_return(NULL);
    }
    mmk_mock_end;
}
this fixes the problem of the void-returning function handling
but it also a whole lot more verbose
Dominik
@kaidowei
hmm that seems a bit overkill
Franklin Mathieu
@Snaipe
I'm not that much of a fan, yeah
Dominik
@kaidowei
mmk_expect and mmk_expect_return and mmk_return should be enough
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