Re: [Check-users] Many leaks when running in fork mode, none in no_fork

[David N. <do...@ma...>]

On Thu, 4 Aug 2016 12:14:36 Branden Archer wrote:
[top post replaced to bottom]
> On Wed, Aug 3, 2016 at 6:16 PM, David Niklas <do...@ma...> wrote:
> 
> > Hello,
> > I've been trying to test my library and I found that though it runs
> > fine when using CK_NOFORK and without, but in the latter case
> > valgrind reports numerous leaks.
> >
> > Examples include:
> > ==23703== 8 bytes in 1 blocks are still reachable in loss record 1 of
> > 58 ==23703==    at 0x4C2B010: malloc (in /usr/lib64/valgrind/
> > vgpreload_memcheck-amd64-linux.so)
> > ==23703== by 0x5200288: emalloc (check_error.c:62)
> > ==23703==    by 0x5200364: check_list_create (check_list.c:61)
> > ==23703==    by 0x51FF6EB: tcase_create (check.c:147)
> > ==23703==    by 0x425407: main (libarmored-ml-tests.check:176)
> >
> > This does not look like part of my program.
> >
> > ==23709== 4 bytes in 1 blocks are still reachable in loss record 1 of
> > 1,831 ==23709==    at 0x4C2B010: malloc (in /usr/lib64/valgrind/
> > vgpreload_memcheck-amd64-linux.so)
> > ==23709==    by 0x56F0F48: re_node_set_init_copy
> > (regex_internal.c:1031) ==23709==    by 0x56F124C: create_cd_newstate
> > (regex_internal.c:1673) ==23709==    by 0x56F124C:
> > re_acquire_state_context (regex_internal.c:1545) ==23709==    by
> > 0x56FBD4C: create_initial_state (regcomp.c:1050) ==23709==    by
> > 0x56FBD4C: re_compile_internal (regcomp.c:814) ==23709==    by
> > 0x56FC869: regcomp (regcomp.c:505) ==23709==    by 0x42431E:
> > libarmored_ml_init (armor-init.c:32) ==23709==    by 0x424A70: setup
> > (libarmored-ml-tests.check:18) ==23709==    by 0x5202BB2:
> > srunner_run_setup (check_run.c:297) ==23709==    by 0x52036BE:
> > tcase_run_checked_setup (check_run.c:324) ==23709==    by 0x52036BE:
> > tcase_run_tfun_fork (check_run.c:463) ==23709==    by 0x52036BE:
> > srunner_iterate_tcase_tfuns (check_run.c:224) ==23709==    by
> > 0x52036BE: srunner_run_tcase (check_run.c:373) ==23709==    by
> > 0x52036BE: srunner_iterate_suites (check_run.c:195) ==23709==    by
> > 0x52036BE: srunner_run (check_run.c:782) ==23709==    by 0x4255EF:
> > main (libarmored-ml-tests.check:189)
> >
> > libarmored_ml_init is mine and is supposed to be called one per
> > libarmored_ml_delete. It is actually silly for it to leak memory
> > since it is fifty lines and I would have noticed it. valgrind would
> > also have noticed it when running in CK_NOFORK mode.
> >
> > Here is the last error (there were many repeats, I may have missed
> > one), again, this is part of my init (two of two allocs).
> >
> > ==23709== 16 bytes in 1 blocks are still reachable in loss record 35
> > of 1,831 ==23709==    at 0x4C2B010: malloc (in /usr/lib64/valgrind/
> > vgpreload_memcheck-amd64-linux.so)
> > ==23709==    by 0x4EDFF30: recode_malloc
> > (in /usr/lib64/librecode.so.0.0.0) ==23709==    by 0x4EDDA75:
> > declare_implied_surface (in /usr/lib64/ librecode.so.0.0.0)
> > ==23709==    by 0x4EDF156: recode_new_outer (in
> > /usr/lib64/librecode.so.0.0.0)
> > ==23709==    by 0x42438F: libarmored_ml_init (armor-init.c:52)
> > ==23709==    by 0x424A70: setup (libarmored-ml-tests.check:18)
> > ==23709==    by 0x5202BB2: srunner_run_setup (check_run.c:297)
> > ==23709==    by 0x52036BE: tcase_run_checked_setup (check_run.c:324)
> > ==23709==    by 0x52036BE: tcase_run_tfun_fork (check_run.c:463)
> > ==23709==    by 0x52036BE: srunner_iterate_tcase_tfuns
> > (check_run.c:224) ==23709==    by 0x52036BE: srunner_run_tcase
> > (check_run.c:373) ==23709==    by 0x52036BE: srunner_iterate_suites
> > (check_run.c:195) ==23709==    by 0x52036BE: srunner_run
> > (check_run.c:782) ==23709==    by 0x4255EF: main
> > (libarmored-ml-tests.check:189)
>
> 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).
AFAIK if the process fork(2)s then all inherited memory is also duplicated
and aught to be free(3)ed as it now belongs to the child.

> Check does just this, notably the test suite structure used to
> define what tests to run. Usually this appears as "still
> reachable" in Valgrind. If CK_NOFORK were used, those resources should
> be cleaned up at the end of the tests.
> 
> 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.
> 
> My advice for avoiding Valgrind's misleading false positives is to run
> Check in the CK_NOFORK mode, if it is practical. If not, attempt to
> detect leaks from Valgrind with the description "definitely lost", as
> they indicated actual memory leaks.
Ok, but how do (un)checked_fixtures work with respect to memory? I want to
make my unit tests call my init and delete functions inside the child.

> A related discussion on memory leaks in Check 0.10.0 appeared in the
> mailing list here, for reference:
> 
> https://sourceforge.net/p/check/mailman/check-users/?viewmonth=201511
> 
> - Branden

Thanks,
David