Tassilo von Parseval <[EMAIL PROTECTED]> writes: >On Thu, Dec 09, 2004 at 01:01:14AM +0000 Sisyphus wrote: > >> >> As I understand it, both the leaker1() and leaker2() functions will leak >> memory, but I'm unable to get Devel::Leak to report it using the above >> script. > >I would say that you cannot use Devel::Leak for that. D::L detects when >you have a leakage with perl data-types.
Correct - and even that isn't absolutely solid. Devel::Leak was originaly a Tk private thing which I used to find out if Tk was leaking SVs/AVs/HVs. It is best used in a loop. >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. > >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. I prefer valgrind too. I still find Devel::Leak useful as it gives Leak info in perl context rather than C context. >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. Snag is that for complex scripts while valgrind tells you yiu have leaked a perl type, it won't tell you where in perl source the leak is. So then adding some Devel:::Leak calls you can try and localize. > >Tassilo
