Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 10 14:41
    Snaipe commented #336
  • Jan 10 09:11
    Bensuperpc closed #335
  • Jan 10 09:10
    Bensuperpc commented #335
  • Jan 10 07:58
    hydrapolic commented #336
  • Jan 10 06:51
    kugel- commented #336
  • Jan 10 05:56
    Snaipe commented #333
  • Jan 09 23:55
    Snaipe commented #223
  • Jan 09 23:52
    Snaipe commented #335
  • Jan 09 23:45
    hydrapolic commented #336
  • Jan 09 23:44
    hydrapolic commented #337
  • Jan 09 23:31
    Snaipe closed #337
  • Jan 09 23:29

    Snaipe on bleeding

    api: fixed zero producing warni… (compare)

  • Jan 09 23:29
    Snaipe closed #330
  • Jan 09 23:28
    Snaipe commented #333
  • Jan 09 23:25
    Snaipe commented #336
  • Jan 09 23:23

    Snaipe on bleeding

    meson: Add/fix options to not-b… (compare)

  • Jan 09 23:23
    Snaipe closed #334
  • Jan 09 23:23
    Snaipe commented #334
  • Jan 09 23:21
    Snaipe commented #337
  • Jan 09 22:26
    hydrapolic opened #337
Franklin Mathieu
@Snaipe
Mimick's new API draft has been fully implemented on branch feature/api-2
A current (working) sample is available here
(it tests a strdup implementation by mocking malloc)
Sundarram P.V. (PVS)
@pvsundarram
Hi,
I am trying to use mimick (btw, thanks for creating it). I am trying to use it in my project for mocking functions that i have created (other than library functions).
It is along the lines of project https://github.com/pvsundarram/try-mimick
I get this error when I try and run the test: ~/Mimick/src/mimick.c:96: Assertion failed: off != NULL
Am I using mimick the right way?
Franklin Mathieu
@Snaipe
@pvsundarram my_fn needs to be inside a shared library -- see the strdup example for a complete example.
(Also, as a heads up, I'd recommend against using Mimick for anything serious right now -- the API ought to change until 1.0 is released.)
Sundarram P.V. (PVS)
@pvsundarram
oh okay. Didn't realise that. Thanks for your help.
Dominik
@kaidowei
@Snaipe hi :) new Memleak
==13897==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13897==    by 0x5B2AFF0: timer_create@@GLIBC_2.3.3 (timer_create.c:63)
==13897==    by 0x4E435E9: setup_timeout (time.c:136)
==13897==    by 0x4E3F7E1: run_test_child (runner.c:177)
==13897==    by 0x4E41908: run_worker (worker.c:84)
==13897==    by 0x4E41A3C: spawn_test_worker (worker.c:111)
==13897==    by 0x4E410CE: run_test (runner_coroutine.c:66)
==13897==    by 0x4E41606: run_next_test (runner_coroutine.c:162)
==13897==    by 0x4E409F0: run_tests_async (runner.c:410)
==13897==    by 0x4E40CEF: criterion_run_all_tests_impl (runner.c:457)
==13897==    by 0x4E40DCB: criterion_run_all_tests (runner.c:482)
==13897==    by 0x4E4921B: main (entry.c:31)
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   fun:timer_create@@GLIBC_2.3.3
   fun:setup_timeout
   fun:run_test_child
   fun:run_worker
   fun:spawn_test_worker
   fun:run_test
   fun:run_next_test
   fun:run_tests_async
   fun:criterion_run_all_tests_impl
   fun:criterion_run_all_tests
   fun:main
}
the test has a timeout... Test(ciosync, cio_sync_copy_output_NULL, .timeout = 3.0 /* seconds */)
Franklin Mathieu
@Snaipe
@kaidowei is the timeout killing that particular test?
because if so, I can't really do much about it -- it's about as abrupt as kill(getpid(), SIGTERM), i.e. no window to clean up
Although I could registrer a signal handler just for that, but it's a bit overkill considering that no matter what happens the test must die, right here, right now
Dominik
@kaidowei
No it's not.
Test running normal
Franklin Mathieu
@Snaipe
This is weird then
does this happen occasionnally, or is it consistently visible?
Actually, nevermind -- I didn't fully remember how the timeout was implemented
I'll come up with a fix soon
Dominik
@kaidowei
@Snaipe a coworker found another interesting thing
[====] Running 6 tests from confparse_complex:
[RUN ] confparse_complex::confcopy_ar7cfg
[RUN ] confparse_complex::confcopy_ifaceconfig
[ERR ] Could not link back the event PID to the active workers.
[ERR ] The event pipe might have been corrupted.
only occurs with -jX (X>1) with cr_assert_file_contents_eq_str()
and not always, but with about 50% chance
currently, we do not have a minimal working example, but I can test for you
the function that provokes the error:
static void verify_complex_config(struct ar7cfg **cfg)
{
    OUTSTREAM *os;
    FILE *fexpected;

    static char saved[8<<20];

    cr_assert_not_null(saved);
    os = outstream_mem(saved, sizeof(saved));
    cr_assert_not_null(os);

    /* Update the tests whenever the defaults in ar7cfg.tab change */
    ASSERT_EQUAL((*cfg)->mode, dsldmode_router);
    ASSERT_STRING_EQUAL((*cfg)->active_provider, "tonline");
    ASSERT_EQUAL((*cfg)->mtu_cutback, 1500);

    config_varsave_topsection_ostream(AR7CFG_ar7cfg_struct, os, (void **)cfg, AR7CFG_ar7cfg_struct->offset, 0);

    fexpected = fopen("expected", "r");

    //~ cr_assert(!feof(fexpected) && !ferror(fexpected));
    cr_assert_file_contents_eq_str(fexpected, saved);

    fclose(fexpected);
    outstream_close(os);
}
Franklin Mathieu
@Snaipe
Might be the result of an out of bounds -- I would gladly accept the example so I can get myself to debug
Dominik
@kaidowei
as I said, no working minimal example...
sorry, can't reproduce it without our complete code...
Dominik
@kaidowei
Update:
if we call cr_file_match_str everything works fine, but the macro seems to cause the problem
when we use cr_assert_file_contents_neq_strinstead of cr_assert_file_contents_eq_strthe string parameter is cropped
in the resulting error message
and the 8<<20 is not a problem. Even if we malloc the buffer, criterion still fails
Franklin Mathieu
@Snaipe
It seems very similar to the out of bounds I fixed for 2.2.1 -- it's possible that this is related and that I missed the issue.
Dominik
@kaidowei
we should think about a bug hunting bounty program ;)
Franklin Mathieu
@Snaipe
I can only pay in coffee at the moment though :D
But yeah, these bugs are the result of me rushing 2.0
Rushing a release never does well for a project.
Dominik
@kaidowei
tell me about it... our PM is rushing all the time :p
Dominik
@kaidowei
it's okay, we have coffee here too :)
update: if we provide a custom message for the assert, there is no problem (seems reasonable)
maybe there is a problem with the pipe and (very long) strings
he says without the send_event there is no problem
Franklin Mathieu
@Snaipe
right
I think that since saved is passed through the pipe with the default message
it just tries to handle it and dies
or rather than dying, corrupts the pipe
Dominik
@kaidowei
a bit strange, that this only happens in 50% of the cases
Franklin Mathieu
@Snaipe
it really depends on the state of the pipe tbh
if the pipe is almost full and you try to push 8 << 20 bytes down its throat, it might lead to this particular problem
which is probably why you can't reproduce it in a minimal example, there needs to be other tests run in parallel that push data down the pipe
this is all supposition though, I'll have to make some tests on my end