Cutter

Hi,

In <20120107001340.GC1610@...>
  "[cutter-users-en] Memory debugging with Valgrind" on Sat, 7 Jan 2012 00:13:40 +0000,
  "Eric P. Mangold" <eric@...> wrote:

> I just started using Cutter today, and mostly I'm very impressed with
> it. I've ported my test suite from another unit-test framework - and it
> is running correctly.

Great!

> The problem is when I try to run my test suite under Valgrind in order
> to detect any memory leaks and other problems that my test-suite may
> expose.
> 
> There are well over 300 reported errors internal to the cutter library,
> presumably becase it's not cleaning up dynamic memory before quitting
> the process... The other unit-test framework I was using made this
> use-case easy, as my test-suite was compiled to an executable (as
> opposed to a library), and it could be run under valgrind without issue.

It's caused by GLib. GLib is a generic utility
library. Cutter is based on GLib.

GLib implements object system as GObject. GObject exports
initialize function but doesn't export finalize function. So
some allocated memories aren't cleaned. Valgrind says they
are "possibly lost" or "still reachable".

> Any ideas how I might solve this, or develop a workaround are
> appreciated.

I don't have a good idea but have some hints:

  * You should add "--keep-opening-modules" option to
    cutter. (See also test/run-test.sh in Cutter source tar.gz.)
    If you don't add the option, Valgrind don't report any
    errors of your program because Cutter unload test
    program, a shared library. 

  * You can determine whether you can ignore an error report
    by backtrace. If a backtrace includes your project's
    path, your project may have a memory leak. Otherwise,
    the error report doesn't have a relationship with your
    project.

    For example, Cutter includes a sample project that uses
    Cutter in $PREFIX/share/cutter/stack. You can create a
    program that has a memory leak with the following changes.

    before (test/test-stack.c):
      void
      teardown (void)
      {
          if (stack)
              stack_free(stack);
      }

    after (test/test-stack.c):
      void
      teardown (void)
      {
      /*
          if (stack)
              stack_free(stack);
      */
      }

    With changed pogram, you will get the following Valgrind output:

      ==30825== 4 bytes in 1 blocks are indirectly lost in loss record 8 of 1,101
      ==30825==    at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==30825==    by 0x4C27927: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==30825==    by 0x7E04793: stack_realloc (stack.c:50)
      ==30825==    by 0x7E0485A: stack_push (stack.c:66)
      ==30825==    by 0x7C01FE0: test_push (test-stack.c:35)
      ==30825==    by 0x4E807DE: invoke (cut-test.c:422)
      ==30825==    by 0x4E80A64: run (cut-test.c:471)
      ==30825==    by 0x4E80BC4: cut_test_run (cut-test.c:515)
      ==30825==    by 0x4E73375: run_test (cut-test-case.c:416)
      ==30825==    by 0x4E73500: run (cut-test-case.c:451)
      ==30825==    by 0x4E7395E: run_tests (cut-test-case.c:561)
      ==30825==    by 0x4E73D00: cut_test_case_run_tests (cut-test-case.c:632)

    The output include "stack.c:50" and
    "stack.c:66". cut-*.c are Cutter library programs but
    stack.c is our program. If a backtrace includes our
    program file, it will be our problem not Cutter.
    
  * You may determine whether your project has a problem or
    not by. If there are "definitely lost" or "indirectly
    lost" blocks, your project may have a problem.

    For example, here is an output by the above program that
    has a memory leak:

      ==30813== LEAK SUMMARY:
      ==30813==    definitely lost: 32 bytes in 2 blocks
      ==30813==    indirectly lost: 4 bytes in 1 blocks
      ==30813==      possibly lost: 34,305 bytes in 162 blocks
      ==30813==    still reachable: 99,593 bytes in 947 blocks
      ==30813==         suppressed: 0 bytes in 0 blocks

    Here is an output by the original stack program:

      ==31368== LEAK SUMMARY:
      ==31368==    definitely lost: 0 bytes in 0 blocks
      ==31368==    indirectly lost: 0 bytes in 0 blocks
      ==31368==      possibly lost: 34,305 bytes in 162 blocks
      ==31368==    still reachable: 99,577 bytes in 946 blocks
      ==31368==         suppressed: 0 bytes in 0 blocks

    Cutter will be reported "possibly lost" and "still
    reachable" but not reported "definitely lost" and
    "indirectly lost".


I hope that they help you.


Thanks,
--
kou