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
Thanks for the reminder Nick, I forgot about this tool. but as you have you need to have a clue of where it comes from :( I'll keep on looking.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
