Re: 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...

Comment on Re: understanding devel::leak Select or Download Code

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]
Re^3: understanding devel::leak by almut (Canon) on Oct 04, 2007 at 13:23 UTC
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]
Re^4: understanding devel::leak by jczeus (Monk) on Oct 05, 2007 at 07:18 UTC
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]
Re^5: understanding devel::leak by almut (Canon) on Oct 05, 2007 at 12:30 UTC
Re^6: understanding devel::leak by jczeus (Monk) on Oct 16, 2007 at 09:42 UTC


No such thing as a small change
	PerlMonks