Front page | perl.perl5.porters |
Postings from September 2011
On Mon Sep 05 02:31:41 2011, nicholas wrote: > 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) Neither did I, but that seems to have changed slightly. Padlists’ contents need special treatment when they are freed (*why* I don’t know, but it would just be a matter of reading the code in cv_undef to find out), so we don’t want sv_clear messing with it after we’ve freed it. That’s basically why AvREAL has to be offe. > > > 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, That was what I did. I was posting my discoveries as I went. > not by trying to reason through what "is" > happening > (as invariably it isn't quite happening that way) or insights into how > things > work.Thread Previous | Thread Next