Re: Valgrind, Perl, and banishing leaks

In addition to setting PERL_DESTRUCT_LEVEL=2 you should also set PERL_DEBUG=1 and PERL_VALGRIND=1.

Last year, I asked P5P about a valgrind memory leak I was seeing but noone responded. In my test case:

PERL_DEBUG=1 PERL_VALGRIND=1 PERL_DESTRUCT_LEVEL=2
 valgrind --leak-check=full perl -e 'sub k {1}'
[download]

produced no memory leak report from valgrind, while:

PERL_DEBUG=1 PERL_VALGRIND=1 PERL_DESTRUCT_LEVEL=2
 valgrind --leak-check=full perl -e 'sub k () {1}'
[download]

produced:

==4943== Memcheck, a memory error detector for x86-linux.
==4943== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et a
+l.
==4943== Using valgrind-2.4.0, a program supervision framework for x86
+-linux.
==4943== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et a
+l.
==4943== For more details, rerun with: -v
==4943==
==4943==
==4943== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 
+1)
==4943== malloc/free: in use at exit: 3 bytes in 1 blocks.
==4943== malloc/free: 775 allocs, 774 frees, 84102 bytes allocated.
==4943== For counts of detected errors, rerun with: -v
==4943== searching for pointers to 1 not-freed blocks.
==4943== checked 282624 bytes.
==4943==
==4943== 3 bytes in 1 blocks are definitely lost in loss record 1 of 1
==4943==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
==4943==    by 0x80C698C: Perl_safesysmalloc (util.c:78)
==4943==    by 0x80C8152: Perl_savepv (util.c:774)
==4943==    by 0x80A5AE6: Perl_newCONSTSUB (op.c:4554)
==4943==    by 0x80A4994: Perl_newATTRSUB (op.c:4305)
==4943==    by 0x8097207: Perl_yyparse (perly.y:364)
==4943==    by 0x806433E: S_parse_body (perl.c:1844)
==4943==    by 0x8062FBA: perl_parse (perl.c:1308)
==4943==    by 0x805F658: main (perlmain.c:96)
==4943==
==4943== LEAK SUMMARY:
==4943==    definitely lost: 3 bytes in 1 blocks.
==4943==      possibly lost: 0 bytes in 0 blocks.
==4943==    still reachable: 0 bytes in 0 blocks.
==4943==         suppressed: 0 bytes in 0 blocks.
==4943== Reachable blocks (those to which a pointer was found) are not
+ shown.
==4943== To see them, rerun with: --show-reachable=yes
[download]

BTW, I'm eager to improve my skills in this area, so if anyone knows some useful links, please let me know.

Update: At the time I wrote this, I didn't realise that functions containing an empty prototype are candidates for inlining (see "Constant Functions" section in perlsub for more details).

Comment on Re: Valgrind, Perl, and banishing leaks Select or Download Code

Replies are listed 'Best First'.

Re^2: Valgrind, Perl, and banishing leaks
by creamygoodness (Curate) on May 19, 2006 at 15:42 UTC

Setting PERL_VALGRIND=1 and PERL_DEBUG=1 didn't change my results.

My debugperl is built from the 5.8.8 source; grepping both that and bleadperl's source for VALGRIND didn't turn up any change in behavior; it looks like the only thing PERL_VALGRIND does is turn on some tests. A similar grep for PERL_DEBUG was produced more voluminous output which was harder to scour; nothing that would change memory management jumped out at me, though maybe I missed something.

In contrast, PERL_DESTRUCT_LEVEL affects perl_destruct in perl.c rather dramatically. Perhaps the system that this perl is built on (RedHat 9) has something to do with our divergent results.

BTW, I'm eager to improve my skills in this area, so if anyone knows some useful links, please let me know.

If you're still following p5p, you may have seen this, but there was a thread recently on running Perl's test suite under Valgrind

--
Marvin Humphrey
Rectangular Research ― http://www.rectangular.com

[reply]
[d/l]
[select]


XP is just a number
	PerlMonks