tracking down a memory leak in $

edan has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: tracking down a memory leak in $_ by shmem (Chancellor) on Jul 20, 2006 at 08:48 UTC
As some general advice, check all places where you append to $_, check all places where you don't localize $_, check all places where you take a reference to $_, check all places where $_ is used implicitly. Without code there's not much more I could say. --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply]
Re: tracking down a memory leak in $_ by perrin (Chancellor) on Jul 20, 2006 at 13:52 UTC
If what you mean is that your program grows over time, that doesn't indicate a memory leak. A leak is when memory is allocated and then becomes unaccessible and is never used again. Chances are, your program is growing because it needs the memory for something you're doing. For advice on how to avoid using too much memory with Perl, see the mod_perl book.	[reply]
Re^2: tracking down a memory leak in $_ by edan (Curate) on Jul 20, 2006 at 19:09 UTC
Well... if I run the exact same code over and over again in a loop, I might expect it to grow the first few times as various things are allocated, but if it consistently continues to grow after executing the same code after dozens and hundreds of loops, I consider that a leak. I don't care if perl is holding a pointer to it somewhere in its bowels - if it keeps allocating more memory in each loop, it's a leak in my book... As I said, I'm pretty sure that it's `$_` that's growing. I don't see anything that's obviously requiring more and more space in `$_`. So isn't that a leak? I really wish I could boil it down to a simple test case, but I'm still puzzled as to exactly what aspect of the code is causing the leak... -- edan	[reply] [d/l] [select]
Re^3: tracking down a memory leak in $_ by perrin (Chancellor) on Jul 20, 2006 at 19:40 UTC
If the data that you put in $_ or any other variable becomes larger at some point, then the memory grows, and it stays larger. The memory will get reused for that variable, but it won't be returned. One thing that often bites people is that reading a nested hash can create hash keys and use more memory. For example: `$foo{bar}->{baz}->{quux};` [download] If there was no baz key before, there is now, and that takes some space.	[reply] [d/l]
Re: tracking down a memory leak in $_ by eyepopslikeamosquito (Bishop) on Jul 20, 2006 at 11:49 UTC
Tracking down memory leaks at the C level is best done with a tool, such as valgrind; for an example of doing this with perl, see Re: Valgrind, Perl, and banishing leaks. If you post a short program demonstrating your memory leak, I'd be interested in having a look at it.	[reply]
Re: tracking down a memory leak in $_ by shonorio (Hermit) on Jul 20, 2006 at 12:50 UTC
Maybe Devel::Leak can help you on this hard job to find a memory leak. Solli Moreira Honorio Sao Paulo - Brazil	[reply]
Re: tracking down a memory leak in $_ by diotalevi (Canon) on Jul 20, 2006 at 13:31 UTC
You should try this with bleadperl too. Your leak (if it exists) might already be fixed. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re: tracking down a memory leak in $_ by eyepopslikeamosquito (Bishop) on Jul 20, 2006 at 21:53 UTC
Because of Perl's reference-count based memory management, circular references will cause memory leaks. To help you find them, see: Devel::Cycle Test::Memory::Cycle	[reply]


Don't ask to ask, just ask
	PerlMonks

tracking down a memory leak in $_