Tassilo von Parseval wrote:
I would say that you cannot use Devel::Leak for that. D::L detects when you have a leakage with perl data-types. In your script however it's not the SVs that leak...it's the memory you allocated with 'Newz' and that you associated with the SVs via PV pointer. Both leaker1 and leaker2 return mortal SVs that are properly cleaned up by perl on leaving the for-block in your two test routines.
Yep - looks like that's the case. I've just written a leaker3() that returns non-mortalised SV's via the Stack - and those leaks *do* get detected.
And the Devel::Leak documentation *does* state that the module examines only the "perl internal table of allocated" things.
At least this is how I understand Devel::Leak. Nick could give more authorative comments on that in case I was wrong.
I only use plain C memory debuggers such as valgrind or dmalloc. I prefer valgrind because you don't have to alter your code to test for memory leaks. If you compile your extensions with OPTIMIZE=-g you will get very accurate results. And these results include not just memory you allocated manually but also perl types that leak due to wrong mortalizing or ref-counting.
Yes, I read (and have retained) that post of yours from the thread that Tels initiated, where you mentioned valgrind. I've even got so far as installing valgrind on my Linux box - though I don't think there's a Win32 port of it - which is one reason that I hoped Devel::Leak would do the job. Another reason is that I find tools like valgrind a little bit intimidating.
Anyway - valgrind is the tool for the job, and I should just "get to it" :-)
Thanks Tassilo.
Cheers, Rob
