Scalars leaked: 1 leaked: sv=0x9d155d4 flags=0x0880003 refcnt=0, Perl interpreter: 0x89bdd40
but how do you figure out what 0x9d155d4 is? I have tried to go and add sv_dump to that reporting code, but the information it gives is usually useless, since the scalar is either almost destroyed or it's some magic object which you have no idea where did it come from.
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.
Anybody has an idea how to pinpoint that variable (if it's in the perl tree) or else w/o doing the guesswork?
My original idea was to feed the reported address back to perl on the next rerun, so assuming that memory allocations will be the same it'll be able to tell me where the leaked scalar was originated from, reporting me the line in perl code or giving me a core backtrace to show when that perl or C variable was created. Once I know that, figuring out how the leak has happened is much easier. Unfortunately under complex setups like modperl, you rarely get the same memory allocations, so I doubt that approach will work.
It seems like ithreads are heavily undertested and there are tons of leakages, many of which were already fixed and many more are waiting to be discovered. So having a good tool to debug those ithreads leaks would be very helpful.
If you know how to handle that problem, please share your techniques. Thanks a lot!
-- __________________________________________________________________ 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
