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

[Branden A. <b.m...@gm...>]

>
> 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.


Generally this is true.

When using fork mode with Check each unit test is forked into its own
process. If the unit test fails _exit() is invoked. Otherwise,
exit(EXIT_SUCCESS) is invoked.

As the client will write the code which initializes Check by creating test
cases, suites, and runners, it is the client's responsibility to properly
free these resources with the provided API. I suppose that if one were
interested in freeing these in each unit test to prevent valgrind from
indicating that a memory allocation is reachable but not freed on process
exit one could add code so that each unit test freed the structures. Maybe
this would be done in a checked fixture. That would be a bit pedantic, but
should be feasible.

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.


The unchecked fixtures are run prior to running the test cases, and are
done before the fork(). The checked fixtures run after the fork(). If there
are resources you would like to create and free per unit test you may want
to do it in a checked fixture.

Hope this helps.

- Branden



On Fri, Aug 5, 2016 at 6:31 PM, David Niklas <do...@ma...> wrote:

> 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
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Check-users mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/check-users
>