in reply to understanding devel::leak

Is there anything missing that compiling with -DDEBUGGING would add?

Yes, if your perl had been built with -DDEBUGGING, Devel::Leak would call its (then available) routine sv_dump() on the things in question, which would produce output similar to what you'd get with the module Devel::Peek. How much that helps, though, will depend on the particular situation...

Anyhow, most problems with memory leaks in Perl code are related to circular references. Consider the following 

for (1..1000000) {
    my $h = {};
    $h->{myself} = $h;
}

[download]

This harmlessly looking piece of code consumes about 130MB (on my machine). Reason is that the anonymous hashes (referenced by $h) are not being freed, because they're holding a reference to themselves, so their reference count doesn't drop to zero when the $h goes out of scope...

Replies are listed 'Best First'.
Re^2: understanding devel::leak
by nonnonymousnonk (Novice) on Oct 04, 2007 at 11:30 UTC
    Thanks for clarifying the debugging thing, I had a feeling something must be missing. If anyone has any pointers to getting devel::leak fully working I'd be grateful.

    I don't think I've created any circular references, I've certainly not got any re-entrant code. However, I have loads of anonymous arrays. I did find_cycle and Dump() a few variables at function exit points and found all had ref counts greater than 1. I'll see what I can find with devel::peek.

    edit Oops, Dump() is devel::peek, I was associating it with data::dumper. Ho hum.

    I've just added an undef ....; to the end of all relevent functions to correspond with all the my ......; but I feel like I'm guessing. There must be a better way to get an idea of memory use than watching perfmon.

[reply]
      I've just added an undef ....; to the end of all relevent functions to correspond with all the my ......;

      Whether undef-ing works, depends on what exactly you undef. In the trivial example above, undef $h at the end of the loop wouldn't help (as that's implicitly happening anyway), while undef %$h, undef $h->{myself} or delete $h->{myself} would help. Point is that you have to break the circle before the data structure becomes unreachable...

      In real life, self-referencing circles are often not immediately evident, as they may come into being indirectly through several data structures, e.g. A references B, which references C, which ... references A — or some such. Your ref counts > 1 might hint at such a situation, unless you have another good explanation for them :)

      Sometimes (if all else fails), it helps to step by step disable parts of the program, until the problem goes away. In this case, look more closely into whatever that last part was, etc. — Without seeing any actual code, it's hard to come up more specific tips.

[reply]
[d/l]
[select]
        Ever tried Devel::Cycle? I'm using it myself right now for finding a memory leak in a long-running POE application.
[reply]
[d/l]

In Section Seekers of Perl Wisdom