Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • 18:52
    BSFishy opened #338
  • 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
Sundarram P.V. (PVS)
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
@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)
oh okay. Didn't realise that. Thanks for your help.
@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)
   match-leak-kinds: definite
the test has a timeout... Test(ciosync, cio_sync_copy_output_NULL, .timeout = 3.0 /* seconds */)
Franklin Mathieu
@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
No it's not.
Test running normal
Franklin Mathieu
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
@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];

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

    /* 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);

Franklin Mathieu
Might be the result of an out of bounds -- I would gladly accept the example so I can get myself to debug
as I said, no working minimal example...
sorry, can't reproduce it without our complete code...
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
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.
we should think about a bug hunting bounty program ;)
Franklin Mathieu
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.
tell me about it... our PM is rushing all the time :p
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
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
a bit strange, that this only happens in 50% of the cases
Franklin Mathieu
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
I'm curious if this would happen with the I/O rewrite on bleeding, though
good idea with the multiple tests