develooper Front page | perl.perl5.porters | Postings from March 2001


Thread Previous | Thread Next
Alan Burlison
March 5, 2001 09:06
Message ID:
Gurusamy Sarathy wrote:

> Consider this piece of code:
>       sub X {
>           my $n = 10;
>           sub { print $n }
>       }
>       my $x = X();
>       undef &X;      # or a redefinition of X() via eval"" or *X = ...
>       $x->();
> There are three CVs there: X(), the prototype anonymous sub within
> X(), and the clone of the anonymous sub (generated via pp_anoncode())
> that gets put in $x.  Note how the lifetime of $x can extend beyond
> that of X().  The lifetime of the prototype sub is tied to the lifetime
> of X(), so it doesn't need to own a refcount on X(), but $x does need
> to keep a refcount to X() if any evals within it are expected to "see"
> lexicals within X().

I get it.  In your example case the lexicals (and therefore pad?) inside
X have to be kept 'alive' for as long as $x is in scope.  Ouch.  I
hadn't considered that.

As a quick hack I had knocked out the SvREFCNT_inc of outsidecv in
Perl_start_subparse().  You'll be glad to know that about 90% of all the
Purify errors disappeared from 'make test', although a number of
'Attempt to free unreferenced scalar' messages appeared (hardly
surprising ;-)

> Incidentally, that example will segfault without the patch I sent.

Are you happy with the last rev of the patch, or are you intending to
respin it again?  I'm itching to try a full 'make test' run with that
and the earlier 'reset' patch you sent out, I'm hopeful that you'll have
made a *major* dent in the leaks.  My 'trash the stash' code has been
causing the generation of lots of errors when PL_strtab is cleared,
mainly I think because of this refcount loop (the problem dissapears
with my horrid hack).  Because of that I havn't put it back into
pureperl yet.

Alan Burlison

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About