On Wed, Feb 23, 2005 at 11:40:09PM -0500, Stas Bekman wrote:
The scalars leaking reporting needs to be improved. At the moment if you get a scalars leaked reported and it didn't happen when you've added that new line of XS/C code you really have no idea where does it coming from. With -DDEBUG_LEAKING_SCALARS the best you can get is:
Scalars leaked: 1 leaked: sv=0x9d155d4 flags=0x0880003 refcnt=0, Perl interpreter: 0x89bdd40
but how do you figure out what 0x9d155d4 is?
Part of what DEBUG_LEAKING_SCALARS enables is that it gives you a real S_new_SV() function (it's normally a macro) that you can point a debugger at, ie set a breakpoint on the last line of that function, then set a breakpoint condition that sv == the address in question. Of course this is fairly slow, and I've been tempted to to add a test into the that code for PL_watchaddr instead.
Due to the fact that the alloc address changes (mod_perl2) on every execution that doesn't work (even with PERL_HASH_SEED=0).
Do you think it's possible to do the following? Have a special mode where
1) each sv is extended to store an extra information (like line/file info when it was created and last modified)
2) have perl free none of the svs for real, so if there is a leak one could examine, both the leaked variable and who uses it (e.g. in case of an magic object).
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.
That's more of a bugger. I find setting PERL_HASH_SEED=0 sometimes helps getting more consistent adddresses, but like you say, in mod_perl it's going to be harder.
it rather seems to be impossible, than just harder (due to the address change)
-- __________________________________________________________________ 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
