On Fri, Apr 09, 2004 at 11:31:04PM +0100, Nicholas Clark wrote:
> On Fri, Apr 09, 2004 at 11:26:57PM +0100, Dave Mitchell wrote:
> > On Fri, Apr 09, 2004 at 07:36:27PM +0100, Nicholas Clark wrote:
> > > On Fri, Apr 09, 2004 at 01:51:02AM +0100, Nicholas Clark wrote:
> > > For the moment I've checked in this change, which side steps the problem.
> > > I'm not sure if this is really actually a bug, given that the item popped
> > > from the savestack could not have been an array (its pointer isn't bitflipped)
> > >
> > > @@ -1035,8 +1045,10 @@
> > > break;
> > > case SAVEt_COMPPAD:
> > > PL_comppad = (PAD*)SSPOPPTR;
> > > - if (PL_comppad)
> > > + if (PL_comppad && SvTYPE(PL_comppad) != SVTYPEMASK) {
> > > + assert(SvTYPE(PL_comppad) == SVt_PVAV);
> > > PL_curpad = AvARRAY(PL_comppad);
> > > + }
> > > else
> > > PL_curpad = Null(SV**);
> > > break;
The following change to bleedperl fixes the problem. During final global
descruction, after all objects have been freed, all SVs are freed in
random order, meaning that the current pad could be freed, then CVs could
be freed, causing PL_comppad to be saved and restored, even though its
been freed.
Dave.
--
Technology is dominated by two types of people: those who understand what
they do not manage, and those who manage what they do not understand.
Change 22688 by [EMAIL PROTECTED] on 2004/04/11 14:27:26
Stop PL_comppad pointing to a freed pad during global destruction
Affected files ...
... //depot/perl/sv.c#735 edit
Differences ...
==== //depot/perl/sv.c#735 (text) ====
@@ -448,6 +448,10 @@
{
DEBUG_D((PerlIO_printf(Perl_debug_log, "Cleaning loops: SV at 0x%"UVxf"\n",
PTR2UV(sv)) ));
SvFLAGS(sv) |= SVf_BREAK;
+ if (PL_comppad == (AV*)sv) {
+ PL_comppad = Nullav;
+ PL_curpad = Null(SV**);
+ }
SvREFCNT_dec(sv);
}
