Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: Make Perl use real malloc

by ikegami (Patriarch)
on Mar 15, 2011 at 05:58 UTC ( [id://893245]=note: print w/replies, xml ) Need Help??


in reply to Make Perl use real malloc

To pass defines the the C compiler rather than the configuration system, use

sh Configure -Accflags="-D... -D..."

Note that one of Configure's prompts asks what allocator you want to use. Wouldn't that be a better way to go?

But I thought valgrind worked with the default configuration on linux?

Good luck!

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

    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]

    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.

      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)

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://893245]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (7)
As of 2024-03-28 10:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found