Greets,
Before each release of KinoSearch, which is an XS distro, I run the
test suite under Valgrind, logging the results. Eyeballing the log, I can
verify that at least the ERROR SUMMARY for each test is 0.
Checking for leaks is tougher. I have a debugging perl compiled, and I set
the PERL_DESTRUCT_LEVEL environment variable to 2, as per the
instructions in perlhack. However, perl still seems to have some
leaks no matter what.
Here's plain perl:
$ valgrind --leak-check=full perl -e1
==5030== Memcheck, a memory error detector.
==5030== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et a
+l.
==5030== Using LibVEX rev 1471, a library for dynamic binary translati
+on.
==5030== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==5030== Using valgrind-3.1.0, a dynamic binary instrumentation framew
+ork.
==5030== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et a
+l.
==5030== For more details, rerun with: -v
==5030==
==5030==
==5030== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 21 from
+1)
==5030== malloc/free: in use at exit: 46,178 bytes in 549 blocks.
==5030== malloc/free: 654 allocs, 105 frees, 53,220 bytes allocated.
==5030== For counts of detected errors, rerun with: -v
==5030== searching for pointers to 549 not-freed blocks.
==5030== checked 325,632 bytes.
==5030==
==5030== 1,211 (104 direct, 1,107 indirect) bytes in 1 blocks are defi
+nitely lost in loss record 1 of 3
==5030== at 0x401A619: malloc (vg_replace_malloc.c:149)
==5030== by 0x8098B14: Perl_safesysmalloc (in /usr/local/bin/perl)
==5030== by 0x809AA63: Perl_my_setenv (in /usr/local/bin/perl)
==5030== by 0x8060011: perl_parse (in /usr/local/bin/perl)
==5030== by 0x805E417: main (in /usr/local/bin/perl)
==5030==
==5030== LEAK SUMMARY:
==5030== definitely lost: 104 bytes in 1 blocks.
==5030== indirectly lost: 1,107 bytes in 24 blocks.
==5030== possibly lost: 0 bytes in 0 blocks.
==5030== still reachable: 44,967 bytes in 524 blocks.
==5030== suppressed: 0 bytes in 0 blocks.
==5030== Reachable blocks (those to which a pointer was found) are not
+ shown.
==5030== To see them, rerun with: --show-reachable=yes
$
... and here's the debugging perl:
$ valgrind --leak-check=full /usr/local/debugperl/bin/perl -e1
==5028== Memcheck, a memory error detector.
==5028== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et a
+l.
==5028== Using LibVEX rev 1471, a library for dynamic binary translati
+on.
==5028== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==5028== Using valgrind-3.1.0, a dynamic binary instrumentation framew
+ork.
==5028== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et a
+l.
==5028== For more details, rerun with: -v
==5028==
==5028==
==5028== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 21 from
+1)
==5028== malloc/free: in use at exit: 127 bytes in 16 blocks.
==5028== malloc/free: 644 allocs, 628 frees, 74,906 bytes allocated.
==5028== For counts of detected errors, rerun with: -v
==5028== searching for pointers to 16 not-freed blocks.
==5028== checked 288,268 bytes.
==5028==
==5028== 127 bytes in 16 blocks are definitely lost in loss record 1 o
+f 1
==5028== at 0x401A619: malloc (vg_replace_malloc.c:149)
==5028== by 0x80B1EFE: Perl_safesysmalloc (util.c:78)
==5028== by 0x80B3343: Perl_savepvn (util.c:789)
==5028== by 0x8068DD9: Perl_gv_fetchpv (gv.c:754)
==5028== by 0x8065045: S_init_main_stash (perl.c:3510)
==5028== by 0x8061650: S_parse_body (perl.c:1657)
==5028== by 0x8061465: perl_parse (perl.c:1598)
==5028== by 0x805E9E8: main (perlmain.c:97)
==5028==
==5028== LEAK SUMMARY:
==5028== definitely lost: 127 bytes in 16 blocks.
==5028== possibly lost: 0 bytes in 0 blocks.
==5028== still reachable: 0 bytes in 0 blocks.
==5028== suppressed: 0 bytes in 0 blocks.
==5028== Reachable blocks (those to which a pointer was found) are not
+ shown.
==5028== To see them, rerun with: --show-reachable=yes
$
Looks like symbol table stuff, and it's almost certainly harmless, but it
would be nice if it were not there. If all those numbers were zero, then when
any of my tests trigger a non-zero I would know that's a red flag. As it is,
I have to look for patterns. Big stuff is easy, but small stuff might sneak
by.
Anybody else do this kind of debuggery? Do you see the same things?