John Peacock <[EMAIL PROTECTED]> writes:
>
>It's still not going to be easy to track these little buggers down, because by
>the time Perl can tell that a scalar is going to leak, it has already leaked
>(i.e. the information contained within the scalar is mostly gone). Perhaps a
>new Perl level sub within Devel::Peek could be added which would take a memory
>address and dump the contents. You could add this line to an END block and
>see
>if you can catch the scalar /in situ/ before anything has been actually
>deallocated. Of course, the act of adding that code will disturb the memory
>allocation, so there might be a couple of iterations before you figure out
>what
>the correct memory address is to dump the leaker.
Well Devel::Leak (in my CPAN directory) is what did when doing Tk.
It works by recording all the SVs in use at one point
and then comparing them at a later point. It can do sv_dump()s of
the new ones.
But you have to have a clue where problem is in your script.
It isn't fool proof as SVs get reused so it is best to put a loop containing
the suspect construct inside and make sure any AUTOLOADs have happened
before
use Devel::Leak;
...
$mw->bind("<Motion>" => [sub { warn }]); # do it once for AUTOLOAD
$c1 = Devel::Leak::NoteSV($handle); # record
for(1..100) {
$mw->bind("<Motion>" => [sub { warn }]); # do it lots
}
$c2 = Devel::Leak::NoteSV($handle); # check
ok($c2-$c1 <= 1, 1);
>
>John
