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. > 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. -- Nothing ventured, nothing lost.
