Stas Bekman wrote:
Every time I need to resolve a leaked scalar problem, I spend hours trying to guess where could it possibly come from. Now add to that problem the fun of randomness, where sometimes the leaked scalar is happening every 10th run or so, so it's litterally improssible to debug this.
I feel your pain. When I was developing the version objects in the core, I had a persistent leak when I did something particular (the details of which escape me now). And yes, the bugger of it was that by the time Perl noticed that this scalar is going to leak, it has already deallocated pretty much everything from the scalar except the reference count, so there was nothing to examine.
Yup
I did have some luck, I recall, when I would notice that the same memory address was the same. I would manually insert an sv_dump() in the Perl source code, hoping to catch whatever it was that was allocating this thing. Unfortunately in my case, the scalar usually contained an RV, so I would still have no idea what was going on. It would be vastly useful to extend the C-level dumping code to have an sv_rdump which would be a recursive dump (ala Devel::Peek) which could reveal what was really contained in that scalar. This would be incredibly useful to examine hashes and arrays, too, at the C-level.
Right. I do a similar thing when I write my own C/XS code and *I* introduce those leaks incrementally, so it's "easy" to deal with. However in the case where you write a *perl* program, relying on the existing code, you don't have that luxury.
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.
As I've explained in the other reply, while just getting the dump of an sv at times will do the trick (if it's an PV with a string in it or similar), but at other times it will not, since if you either don't know where that scalar lives (like an magic attachement) you won't know where it's coming from, or the scalar is some complicated internal thing, that you have no idea how does it affect your perl code.
-- __________________________________________________________________ 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
