Front page | perl.perl5.porters |
Postings from September 2011
On Wed, Aug 31, 2011 at 09:34:24PM -0700, Father Chrysostomos via RT wrote: > On Wed Aug 31 20:41:39 2011, sprout wrote: > > The other warnings are also the result of padlists in @DB::args. If > > they get cloned through @DB::args, their refcounts are not incremented > > (except for that held by param->unreferenced), hence the double free. > > > > Is there any reason padlists can't be marked AvREAL (so sv_dup_common > > knows to use sv_dup_*inc* on the elems)? In cv_undef, we could turn off > > the REAL flag just before: I don't understand that reasoning as to why padlists aren't "REAL". Given that they (seem to) reference count their contents conventionally, it's always struck me as strange. However, I don't have any real understanding of the deeper aspects of how CVs and pads work (such as closures, and who owns what) > > SvREFCNT_dec(MUTABLE_SV(CvPADLIST(cv))); > > CvPADLIST(cv) = NULL; > > See the smoke-me/avreal-padlist branch. All tests pass for me. Is > anyone reading my monologue? I was (at the time), but didn't have anything useful to add. (Even though it's one of my commits that seems to have been the problem. Oops, sorry) Historically I've only nailed these sorts of messy bugs with a lot of grinding away with gdb, not by trying to reason through what "is" happening (as invariably it isn't quite happening that way) or insights into how things work. Nicholas ClarkThread Previous | Thread Next