http://qs321.pair.com?node_id=893380


in reply to Re^2: Make Perl use real malloc
in thread Make Perl use real malloc

No matter what allocator Perl uses, valgrind can't detect leaked SVs (e.g. reference cycles, refcount to high) if Perl is always aware of its SVs, and that has to be the case since Perl attempts to free them during global destruction.

$ valgrind perl -e'my $x; $x = \$x; undef $x if $ARGV[0]' 1 ==21363== Memcheck, a memory error detector ==21363== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et +al. ==21363== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h fo +r copyright info ==21363== Command: perl -emy\ $x;\ $x\ =\ \\$x;\ undef\ $x\ if\ $ARGV[ +0] 1 ==21363== ==21363== Warning: bad signal number 0 in sigaction() ==21363== ==21363== HEAP SUMMARY: ==21363== in use at exit: 80,794 bytes in 609 blocks ==21363== total heap usage: 786 allocs, 177 frees, 93,378 bytes allo +cated ==21363== ==21363== LEAK SUMMARY: ==21363== definitely lost: 0 bytes in 0 blocks ==21363== indirectly lost: 0 bytes in 0 blocks ==21363== possibly lost: 14,538 bytes in 354 blocks ==21363== still reachable: 66,256 bytes in 255 blocks ==21363== suppressed: 0 bytes in 0 blocks ==21363== Rerun with --leak-check=full to see details of leaked memory ==21363== ==21363== For counts of detected and suppressed errors, rerun with: -v ==21363== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 22 from + 7) $ valgrind perl -e'my $x; $x = \$x; undef $x if $ARGV[0]' 0 ==21366== Memcheck, a memory error detector ==21366== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et +al. ==21366== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h fo +r copyright info ==21366== Command: perl -emy\ $x;\ $x\ =\ \\$x;\ undef\ $x\ if\ $ARGV[ +0] 0 ==21366== ==21366== Warning: bad signal number 0 in sigaction() ==21366== ==21366== HEAP SUMMARY: ==21366== in use at exit: 80,794 bytes in 609 blocks ==21366== total heap usage: 786 allocs, 177 frees, 93,378 bytes allo +cated ==21366== ==21366== LEAK SUMMARY: ==21366== definitely lost: 0 bytes in 0 blocks ==21366== indirectly lost: 0 bytes in 0 blocks ==21366== possibly lost: 14,538 bytes in 354 blocks ==21366== still reachable: 66,256 bytes in 255 blocks ==21366== suppressed: 0 bytes in 0 blocks ==21366== Rerun with --leak-check=full to see details of leaked memory ==21366== ==21366== For counts of detected and suppressed errors, rerun with: -v ==21366== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 22 from + 7)

Replies are listed 'Best First'.
Re^4: Make Perl use real malloc
by creamygoodness (Curate) on Mar 15, 2011 at 18:56 UTC

    I believe that in those examples, Perl is actually leaking the scalars, along with a lot of other stuff -- look at the "still reachable" stat. It's doing this intentionally, by exiting immediately rather than painstakingly deallocating everything first.

    In order to persuade Perl to deallocate everything, you need a Perl compiled with -DDEBUGGING and to set the PERL_DESTRUCT_LEVEL environment variable to 2. You are also likely need to create a Valgrind suppressions file to adapt for miscellaneous noise from libc, Dynaloader, etc.

    In the end, though, you still don't see any difference when running those two examples. I would argue that the proof needed tightening up -- but the reasoning and explanation were sound.

      I believe that in those examples, Perl is actually leaking the scalars, along with a lot of other stuff -- look at the "still reachable" stat. It's doing this intentionally, by exiting immediately rather than painstakingly deallocating everything first.

      The lesson to take was that there is no difference in the valgrind output between the two runs, which demonstrates that it can't detect the scalars that I leaked in the second run.