#64 Check does not free memory properly (valgrind issue)

v1.0 (example)
Tests (10)
Marc Munro

When check forks to run tests, the forked child does not free memory allocated in the parent. This leads to valgrind reporting lost memory unnecessaily.

A simple, low-risk change to tcase_run_tfun_fork in check_run.c fixes this (I have marked the changed lines MM):

static TestResult *tcase_run_tfun_fork (SRunner *sr, TCase *tc, TF *tfun, int i)
pid_t pid_w;
pid_t pid;
int status = 0;
pid = fork();
if (pid == -1)
eprintf("Unable to fork:",__FILE__,__LINE__);
if (pid == 0) {
setpgid(0, 0);
group_pid = getpgrp();
tcase_run_checked_setup(sr, tc);

srunner_end_logging (sr); /* MM - PATCH TO FREE MEMORY BEING CHECKED */
teardown_messaging(); /* MM - BY VALGRIND */
srunner_free(sr); /* MM - */

} else {
group_pid = pid;

alarm_received = 0;
do {
pid_w = waitpid(pid, &status, 0);
} while (pid_w == -1);

killpg(pid, SIGKILL); /* Kill remaining processes. */

return receive_result_info_fork(tc->name, tfun->name, i, status, tfun->signal);

If you would prefer a context diff or sime such, please let me know.



  • Chris Pickett

    Chris Pickett - 2008-11-30

    Hi Marc,

    I tried applying your patch to the SVN head as follows:

    $ svn diff
    Index: src/check_run.c
    --- src/check_run.c (revision 444)
    +++ src/check_run.c (working copy)
    @@ -433,6 +433,12 @@
    tcase_run_checked_setup(sr, tc);
    + /* free memory allocated in parent */
    + srunner_end_logging(sr);
    + teardown_messaging();
    + srunner_free(sr);
    } else {
    group_pid = pid;

    $ make check
    Making check in src
    make[1]: Nothing to be done for `check'.
    Making check in doc
    make[1]: Nothing to be done for `check'.
    Making check in .
    make[1]: Nothing to be done for `check-am'.
    Making check in tests
    make check-TESTS
    Running suite(s): Fork Sub
    100%: Checks: 3, Failures: 0, Errors: 0
    check_check_fork.c:17:P:Core:test_inc:0: Passed
    check_check_fork.c:26:P:Core:test_nofork_sideeffects:0: Passed
    check_check_fork.c:33:P:Core:test_nofork_pid:0: Passed
    Running suite(s): Check Servant
    check_check_export(22741) malloc: *** Deallocation of a pointer not malloced: 0x303d3b; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug

    Can you:

    a) try with the latest SVN
    b) use svn diff > valgrind.patch to get a patch,
    c) run make check

    and let me know what happens?


  • Chris Pickett

    Chris Pickett - 2008-11-30
    • labels: 349487 --> Tests
    • priority: 5 --> 3
    • assigned_to: amalec --> cpickett
  • Chris Pickett

    Chris Pickett - 2008-11-30
    • summary: Check does not play nice with valgrind --> Check does not free memory properly (valgrind issue)
  • Chris Pickett

    Chris Pickett - 2008-11-30

    Note: we're waiting for Marc to get back to us on this before we can proceed.

  • Marc Munro

    Marc Munro - 2008-12-01

    Looks like this has already been addressed in the svn version, at least I guess so from the double free errors I'm seeing. The bug existed in the debian package for version 0.9.5. You can close this bug. Sorry for the noise. Thanks for producing check.

  • Johan Simonsson

    Johan Simonsson - 2009-01-31


    I checked out https://check.svn.sourceforge.net/svnroot/check/tags/check-0.9.6/ and built this version,
    then I ran "valgrind ./check_check" in the test dir and got this back.

    ==1331== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
    ==1331== malloc/free: in use at exit: 8,966 bytes in 351 blocks.
    ==1331== malloc/free: 6,560 allocs, 6,209 frees, 431,445 bytes allocated.
    ==1331== For counts of detected errors, rerun with: -v
    ==1331== searching for pointers to 351 not-freed blocks.
    ==1331== checked 60,648 bytes.
    ==1331== LEAK SUMMARY:
    ==1331== definitely lost: 2,934 bytes in 154 blocks.
    ==1331== possibly lost: 0 bytes in 0 blocks.
    ==1331== still reachable: 6,032 bytes in 197 blocks.
    ==1331== suppressed: 0 bytes in 0 blocks.
    ==1331== Rerun with --leak-check=full to see details of leaked memory.

    It seems like there is a couple of mem leaks in this release.

    The reason I did this was since I want do run valgrind on my own test code for another project,
    but if the unit test framework contains memleaks my own leaks will not show up in my tests.

    Can I help out in the process of smoking them out?


  • Chris Pickett

    Chris Pickett - 2009-01-31

    Hi Johan,

    By all means. Start by checking out the SVN trunk, and then attach whatever patches help you fix your issues to this bug. I'll review them and apply if they don't appear to break anything.

    Thanks for your interest in Check!


  • Branden Archer

    Branden Archer - 2013-12-17

    The check_check unit testing program will have memory leaks in it. This is unavoidable. There are a few unit tests that create internal data structures in various ways, and ensures that they are created properly. As a user is never expected to free those structures manually, the freeing functions are static and inaccessable to unit tests. As a result, without doing some hackery, the structures created in the unit tests will be leaked.

    If you want a simpler example to determine if Check has leaks, use ex_output. That unit tests will work in both FORK and NO_FORK mode, and does everything a normal user would do: create a suite, run a few tests (some fail, some pass), report the result.

    $ valgrind --leak-check=full tests/.libs/ex_output CK_NORMAL

    On my system I do get a few errors, but they are related to something in glibc:
    ==17496== Syscall param timer_create(evp) points to uninitialised byte(s)
    ==17496== at 0x581F30A: timer_create@@GLIBC_2.3.3 (timer_create.c:99)
    ==17496== by 0x4E37958: srunner_run (check_run.c:408)
    ==17496== by 0x400B4B: run_tests (ex_output.c:56)
    ==17496== by 0x400C6C: main (ex_output.c:82)
    ==17496== Address 0x7ff0002e0 is on thread 1's stack

    However, none of the errors were memory leaks.

    Note that I needed to use the version of the program installed under tests/.libs. libtool puts wrappers for the unit test programs under tests, but the real files under tests/.libs. Running valgrind on the wrapper script is not very useful.

    With this, you should be OK to use valgrind against unit tests that use Check. If you find a memory leak in Check itself, though, please let us know by telling us what program exhibited the issue, or provide a minimal example that creates a leak.

  • Branden Archer

    Branden Archer - 2013-12-17
    • status: open --> closed-invalid
    • Group: --> v1.0 (example)
  • Branden Archer

    Branden Archer - 2013-12-18

    A stripped down version of check_check will be added, called check_mem_leaks. This unit tests will include a subset of the unit tests that check_check uses. Tests that intentionally leak memory are not included, as well as tests against non public APIs. The unit test is intended to show that a user, using public APIs, will not leak memory.

    If you would like to see if Check is leaking memory, give that unit tests a try. There is a convenience script, test_mem_leaks.sh, which will invoke valgrind against check_mem_leaks and grep through the results. For me, this returns 0 memory leaks.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks