Re^2: tracking down a memory leak in $

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

Comment on Re^2: tracking down a memory leak in $_ Select or Download Code

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Re^3: tracking down a memory leak in $_
by perrin (Chancellor) on Jul 20, 2006 at 19:40 UTC

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]

[reply]
[d/l]