Re: [Check-users] Possible Memory Leak in 0.10.0

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

If the unit test program is configured to use fork() to run its tests, the
main process will fork() and run the unit tests in the child process. The
child process will eventually terminate, and the main process will detect
this and continue on. The child process will inherit any "baggage" from the
main process. Namely, if a resource is allocated in the main process before
the child process is forked, the child process will not clean up that
resource (as it is not supposed to). This may appear as a leak. Usually
this appears as "still reachable" in Valgrind, so it is interesting that
Valgrind detected something as "definitely lost". Running Check with fork
disabled will prevent such false positives, as the main process will also
host the unit tests and cleanup properly at the end. The memory leak
checking that the Check project does also disables fork() using CK_FORK=no .

Certainly there will be code which can only be run with fork() enabled,
such as code under tests which will exit() and the return code is checked.
For such code, there may be no alternative to avoid false positives.
However, if one can run tests without fork() for memory leak checking with
Valgrind it will be easier.

- Branden

On Tue, Nov 17, 2015 at 10:47 AM, Eric Sheridan <es...@gm...> wrote:

> Thank you for such a prompt and detailed response. I had not considered
> a memory leak in a system library. I'm running OSX 10.10.5.
>
> Per your feedback, running with "CK_FORK=no" yielded no memory leaks
> when executing your exact command. Does this help shed any additional
> light? At a minimum, your prior feedback will help me write similar
> mem-leak integration tests in CI going forward, I'll just have to use
> CK_FORK=no (when on OSX anyway). Thank you.
>
> $ export CK_FORK=no
> $ valgrind --leak-check=full ./main
> ==3948== Memcheck, a memory error detector
> ==3948== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==3948== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
> ==3948== Command: ./main
> ==3948==
> Running suite(s): main
> 100%: Checks: 9, Failures: 0, Errors: 0
> ==3948==
> ==3948== HEAP SUMMARY:
> ==3948==     in use at exit: 38,871 bytes in 418 blocks
> ==3948==   total heap usage: 775 allocs, 357 frees, 172,474 bytes allocated
> ==3948==
> ==3948== LEAK SUMMARY:
> ==3948==    definitely lost: 0 bytes in 0 blocks
> ==3948==    indirectly lost: 0 bytes in 0 blocks
> ==3948==      possibly lost: 0 bytes in 0 blocks
> ==3948==    still reachable: 4,096 bytes in 1 blocks
> ==3948==         suppressed: 34,775 bytes in 417 blocks
> ==3948== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==3948== To see them, rerun with: --leak-check=full --show-leak-kinds=all
> ==3948==
> ==3948== For counts of detected and suppressed errors, rerun with: -v
> ==3948== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 16 from 16)
>
>
>
> On 11/16/15 11:34 PM, Branden Archer wrote:
> > Interesting. At one point I setup a Jenkins job
> > <https://check.ci.cloudbees.com/job/check-linux-sf/> which which would
> > run a memory leak test
> > <
> http://sourceforge.net/p/check/code/HEAD/tree/trunk/tests/test_mem_leaks.sh
> >
> > with Valgrind to avoid a memory leak sneaking into Check
> > unintentionally. That job has not found a memory leak on GNU/Linux, so
> > one might hope that on other platforms all would be well.
> >
> > I attempted to run your example program on Valgrind on my GNU/Linux box,
> > but it did not find anything too interesting:
> >
> >
> > CK_FORK=no valgrind --leak-check=full ./tmp
> > ==13253== Memcheck, a memory error detector
> > ==13253== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> > ==13253== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright
> info
> > ==13253== Command: ./tmp
> > ==13253==
> > Running suite(s): suite
> > ==13253== Syscall param timer_create(evp) points to uninitialised byte(s)
> > ==13253==    at 0x560230A: timer_create@@GLIBC_2.3.3 (timer_create.c:99)
> > ==13253==    by 0x4E34EC8: check_get_clockid (check.c:538)
> > ==13253==    by 0x4E37874: tcase_run_tfun_nofork.isra.12
> (check_run.c:387)
> > ==13253==    by 0x4E37CF5: srunner_run (check_run.c:231)
> > ==13253==    by 0x400996: test_suite (in
> > /home/brarcher/workspace/check/doc/example/tmp)
> > ==13253==    by 0x4009E0: main (in
> > /home/brarcher/workspace/check/doc/example/tmp)
> > ==13253==  Address 0x7ff000790 is on thread 1's stack
> > ==13253==
> > 100%: Checks: 1, Failures: 0, Errors: 0
> > ==13253==
> > ==13253== HEAP SUMMARY:
> > ==13253==     in use at exit: 0 bytes in 0 blocks
> > ==13253==   total heap usage: 39 allocs, 39 frees, 10,298 bytes allocated
> > ==13253==
> > ==13253== All heap blocks were freed -- no leaks are possible
> > ==13253==
> > ==13253== For counts of detected and suppressed errors, rerun with: -v
> > ==13253== Use --track-origins=yes to see where uninitialised values come
> > from
> > ==13253== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
> >
> >
> > ^ In that run something was found in glibc, but not with Check itself.
> >
> > The interesting bit from the run on your machine is the following:
> >
> >
> > ==62129==    at 0x100009EBB: malloc (in
> >
> /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
> > ==62129==    by 0x1001E0696: __smakebuf (in
> > /usr/lib/system/libsystem_c.dylib)
> > ==62129==    by 0x1001F51E7: __swsetup (in
> > /usr/lib/system/libsystem_c.dylib)
> > ==62129==    by 0x1001DF930: __sfvwrite (in
> > /usr/lib/system/libsystem_c.dylib)
> > ==62129==    by 0x1001DFF0A: fwrite (in
> /usr/lib/system/libsystem_c.dylib)
> >
> >
> > Namely, it appears that there is a malloc being involved when fwrite is
> > called. Perhaps that memory is not being freed by by libsystem as it
> should.
> >
> > To rule out any effects with running the unit tests with using fork(),
> > try running the unit test with the following environment variable
> defined:
> >
> > CK_FORK
> > <
> http://check.sourceforge.net/doc/check_html/check_7.html#Environment-Variable-Reference
> >=no
> >
> > If the unit test is still leaking memory at that point, it might be that
> > there is a leak in the implementation of fwrite on your system. That
> > would be strange; one would expect something like that to be better
> tested.
> >
> > I attempted to run your example program on my mac as well (10.10.5)
> > with Valgrind-3.11.0 and was unable to find any issues as well:
> >
> >
> > $ CK_FORK=no valgrind --leak-check=full ./tmp
> > ==36506== Memcheck, a memory error detector
> > ==36506== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> > ==36506== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright
> info
> > ==36506== Command: ./tmp
> > ==36506==
> > Running suite(s): suite
> > 100%: Checks: 1, Failures: 0, Errors: 0
> > ==36506==
> > ==36506== HEAP SUMMARY:
> > ==36506==     in use at exit: 38,903 bytes in 419 blocks
> > ==36506==   total heap usage: 550 allocs, 131 frees, 59,065 bytes
> allocated
> > ==36506==
> > ==36506== LEAK SUMMARY:
> > ==36506==    definitely lost: 0 bytes in 0 blocks
> > ==36506==    indirectly lost: 0 bytes in 0 blocks
> > ==36506==      possibly lost: 0 bytes in 0 blocks
> > ==36506==    still reachable: 4,096 bytes in 1 blocks
> > ==36506==         suppressed: 34,807 bytes in 418 blocks
> > ==36506== Reachable blocks (those to which a pointer was found) are not
> > shown.
> > ==36506== To see them, rerun with: --leak-check=full
> --show-leak-kinds=all
> > ==36506==
> > ==36506== For counts of detected and suppressed errors, rerun with: -v
> > ==36506== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from
> 17)
> >
> >
> > Sorry I cannot be more help.
> >
> > - Branden
> >
> >
> >
> > On Mon, Nov 16, 2015 at 5:03 PM, Eric Sheridan <es...@gm...
> > <mailto:es...@gm...>> wrote:
> >
> >     Team,
> >
> >     I believe I've stumbled across a memory leak within Check. The source
> >     code (see attached) is very basic with *minor* exception to the use
> of a
> >     function pointer to reference a function to create the test suite.
> I'm
> >     new to Check and might be doing something wrong, but I believe I'm
> >     correctly adhering too the alloc/free patterns required by Check.
> >
> >     Valgrind output is below. Am I doing something wrong? Or is this a
> bug?
> >
> >     $ valgrind --leak-check=full ./main
> >     ==62127== Memcheck, a memory error detector
> >     ==62127== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward
> >     et al.
> >     ==62127== Using Valgrind-3.11.0 and LibVEX; rerun with -h for
> >     copyright info
> >     ==62127== Command: ./main
> >     ==62127==
> >     --62127-- run: /usr/bin/dsymutil "./main"
> >     warning: no debug symbols in executable (-arch x86_64)
> >     Running suite(s): suite
> >     ==62129==
> >     ==62129== HEAP SUMMARY:
> >     ==62129==     in use at exit: 44,630 bytes in 448 blocks
> >     ==62129==   total heap usage: 559 allocs, 111 frees, 52,223 bytes
> >     allocated
> >     ==62129==
> >     ==62129== 4,096 bytes in 1 blocks are definitely lost in loss record
> 108
> >     of 108
> >     ==62129==    at 0x100009EBB: malloc (in
> >
>  /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
> >     ==62129==    by 0x1001E0696: __smakebuf (in
> >     /usr/lib/system/libsystem_c.dylib)
> >     ==62129==    by 0x1001F51E7: __swsetup (in
> >     /usr/lib/system/libsystem_c.dylib)
> >     ==62129==    by 0x1001DF930: __sfvwrite (in
> >     /usr/lib/system/libsystem_c.dylib)
> >     ==62129==    by 0x1001DFF0A: fwrite (in
> >     /usr/lib/system/libsystem_c.dylib)
> >     ==62129==    by 0x1000144AF: ppack (in
> >     /usr/local/Cellar/check/0.10.0/lib/libcheck.0.dylib)
> >     ==62129==    by 0x100014092: send_ctx_info (in
> >     /usr/local/Cellar/check/0.10.0/lib/libcheck.0.dylib)
> >     ==62129==    by 0x100015C16: srunner_run_setup (in
> >     /usr/local/Cellar/check/0.10.0/lib/libcheck.0.dylib)
> >     ==62129==    by 0x100015783: srunner_run (in
> >     /usr/local/Cellar/check/0.10.0/lib/libcheck.0.dylib)
> >     ==62129==    by 0x100001D4D: test_suite (in ./main)
> >     ==62129==    by 0x100001DBF: main (in ./main)
> >     ==62129==
> >     ==62129== LEAK SUMMARY:
> >     ==62129==    definitely lost: 4,096 bytes in 1 blocks
> >     ==62129==    indirectly lost: 0 bytes in 0 blocks
> >     ==62129==      possibly lost: 0 bytes in 0 blocks
> >     ==62129==    still reachable: 4,596 bytes in 25 blocks
> >     ==62129==         suppressed: 35,938 bytes in 422 blocks
> >     ==62129== Reachable blocks (those to which a pointer was found) are
> not
> >     shown.
> >     ==62129== To see them, rerun with: --leak-check=full
> >     --show-leak-kinds=all
> >     ==62129==
> >     ==62129== For counts of detected and suppressed errors, rerun with:
> -v
> >     ==62129== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 17
> >     from 17)
> >     100%: Checks: 1, Failures: 0, Errors: 0
> >     ==62127==
> >     ==62127== HEAP SUMMARY:
> >     ==62127==     in use at exit: 38,919 bytes in 420 blocks
> >     ==62127==   total heap usage: 559 allocs, 139 frees, 59,584 bytes
> >     allocated
> >     ==62127==
> >     ==62127== LEAK SUMMARY:
> >     ==62127==    definitely lost: 0 bytes in 0 blocks
> >     ==62127==    indirectly lost: 0 bytes in 0 blocks
> >     ==62127==      possibly lost: 0 bytes in 0 blocks
> >     ==62127==    still reachable: 4,096 bytes in 1 blocks
> >     ==62127==         suppressed: 34,823 bytes in 419 blocks
> >     ==62127== Reachable blocks (those to which a pointer was found) are
> not
> >     shown.
> >     ==62127== To see them, rerun with: --leak-check=full
> >     --show-leak-kinds=all
> >     ==62127==
> >     ==62127== For counts of detected and suppressed errors, rerun with:
> -v
> >     ==62127== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 16
> >     from 16)
> >
> >
>  ------------------------------------------------------------------------------
> >     Presto, an open source distributed SQL query engine for big data,
> >     initially
> >     developed by Facebook, enables you to easily query your data on
> >     Hadoop in a
> >     more interactive manner. Teradata is also now providing full
> enterprise
> >     support for Presto. Download a free open source copy now.
> >     http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
> >     _______________________________________________
> >     Check-users mailing list
> >     Che...@li...
> >     <mailto:Che...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/check-users
> >
> >
>