The canonical examples have already been given, but for a practical example, try something like:
| | | sub make_a_leak {
my $tree = HTML::TreeBuilder->new();
$tree->parse($some_big_html_file);
return;
}
|
Without a call to $tree->delete, the above code will snarf tons of memory, because of all the circular references contained within the TreeBuilder parse-tree.
MeowChow
s aamecha.s a..a\u$&owag.print | [reply]
[d/l] |
Maybe I should RTFM, but I've not had a problem with memory leaks in Perl, so I'm going to claim ignorance. Does anyone know which modules are known for causing problems like this? My mind immediately jumps to binding columns with DBI. Would wrapping calls in an eval help prevent a memory leak?
| [reply] |
If your scripts aren't long-lived (ie. servers, mod_perl handlers), then it's unlikely that you will notice or care about memory leaks. If, however, you are writing code that is expected to stay resident for days, weeks, or months, then certainly memory leaks are a serious issue, as is the related problem of making sure your data structures do not grow unchecked.
AFAIK, the only thing that can cause a memory leak under Perl, outside of badly written XS code, is a circular self-reference, although I'd bet that there are some pathological memory allocation patterns which fragment memory to the point of appearing to cause memory leaks.
The HTML::TreeBuilder example is not really a case of a "module causing problems", since it includes a method for cleaning up after itself. I also wouldn't expect DBI to be a source of any memory leaks, since it's such a well-tested and often-used module. Regarding your last question, wrapping calls inside an eval would do nothing to prevent a memory leak.
MeowChow
s aamecha.s a..a\u$&owag.print | [reply] |
