Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 11 17:41
    jonathanturcotte commented #312
  • Nov 06 16:25
    jonathanturcotte commented #312
  • Nov 06 16:12
    jonathanturcotte commented #312
  • Nov 06 15:56
    Snaipe commented #312
  • Nov 06 15:48
    jonathanturcotte commented #312
  • Nov 06 12:31
    Snaipe commented #312
  • Nov 05 23:41
    jonathanturcotte opened #312
  • Nov 04 18:20
    Snaipe commented #310
  • Nov 04 18:01
    am11 commented on 81982a2
  • Nov 04 11:57
    Snaipe labeled #311
  • Nov 04 11:57
    Snaipe labeled #311
  • Nov 04 11:57
    Snaipe labeled #311
  • Nov 04 11:57
    Snaipe assigned #311
  • Nov 04 11:56

    Snaipe on bleeding

    Update the share directory loca… (compare)

  • Nov 04 11:56
    Snaipe closed #310
  • Nov 04 11:56
    Snaipe commented #310
  • Nov 03 19:38
    lokasho opened #311
  • Oct 31 13:34
    kdridi opened #310
  • Oct 29 21:36
    a1lu synchronize #286
  • Oct 29 11:44
    Snaipe commented #284
Franklin Mathieu
@Snaipe
@faridmes what OS are you on? They details may vary depending on your platform
Farid Mesnata
@lamrii
Ubuntu
Franklin Mathieu
@Snaipe
then follow the instructions over at http://criterion.readthedocs.org/en/master/setup.html (including the sudo make install)
we ought to have a proper package for debian systems in the future, but we currently have some issues with packaging
until then, building from source is the best solution
Farid Mesnata
@lamrii
Ok, I will do that
thanks
Dominik
@kaidowei
@Snaipe hi, I tried to produce a minimal example, but I can't reproduce the leak there
Dominik
@kaidowei
that does it for me, dunno if there are things from our automake, that produce the error
Franklin Mathieu
@Snaipe
This doesn't trigger the leak for me, are you passing specific parameters or setting any environment variable to alter the behaviour of the runner?
Dominik
@kaidowei
--no-early-exit -j1 --pattern confparse_simple/config_load
Franklin Mathieu
@Snaipe
Ah! I can reproduce it now.
Dominik
@kaidowei
yeah :)
Franklin Mathieu
@Snaipe
--pattern exits too early without cleaning up the test stats
Dominik
@kaidowei
btw. 2.2.1 seems to run well ...
Dominik
@kaidowei
@Snaipe
double timeout; /// A timeout for the test in seconds
void *data; /// Extra user data
both are missing in http://criterion.readthedocs.org/en/master/starter.html#configuration-reference
Franklin Mathieu
@Snaipe
this should be fixed in the features/sphinx-doxygen branch (see http://criterion.readthedocs.org/en/features-sphinx-doxygen/starter.html#configuration-reference for what it looks like)
Dominik
@kaidowei
ah okay, sorry then
Franklin Mathieu
@Snaipe
no need to be sorry for that :)
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