Re^2: Make Perl use real malloc

It used to be that the FreeBSD port of Valgrind couldn't work with the system Perl, but that was because the FreeBSD system Perl was built with -Dusemymalloc, which Valgrind can't handle. I don't know of a similar problem with any system Perl in a Linux distro, nor have I seen any problems with a system Perl on OS X. Valgrind works with Perl on all those systems. It also works with Perl on FreeBSD if you custom compile your own Perl without -Dusemymalloc.

The only Configure prompts I know of relating to malloc() control PERL_MALLOC_WRAP and usemymalloc:

Do you wish to wrap malloc calls to protect against potential overflow
+s? [y] n
 
Do you wish to attempt to use the malloc that comes with perl5? [n]
[download]

If we want to work with Valgrind, we definitely don't want to enable usemymalloc (which is disabled by default).

The Accflags="-DNO_FANCY_MALLOC -DPLAIN_MALLOC " Configure flag worked as intended -- thanks for the tip! Unfortunately, it did not produce a Perl that allowed us to use Valgrind in place of Test::LeakTrace.

Maybe what we want is impossible because of how the global destruction phase works in Perl. If we use a debugging Perl and set PERL_DESTRUCT_LEVEL to 2, Perl will clean up all scalars, regardless of their refcounts. If we don't set PERL_DESTRUCT_LEVEL, it drops everything on the floor and lets the process exit() clean things up. There's no middle ground where it leaves only scalars with leaked refcounts behind.

Comment on Re^2: Make Perl use real malloc Select or Download Code

Replies are listed 'Best First'.
Re^3: Make Perl use real malloc by ikegami (Patriarch) on Mar 15, 2011 at 17:11 UTC
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) [download]	[reply] [d/l]
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. Read more... (3 kB)	[reply] [d/l] [select]
Re^5: Make Perl use real malloc by ikegami (Patriarch) on Mar 15, 2011 at 19:11 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. 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.	[reply]


The stupid question is the question not asked
	PerlMonks