"[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.
> 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
> 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
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
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.
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
I hope that they help you.