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


Thread Previous | Thread Next
Alan Burlison
March 5, 2001 03:02
Message ID:
Gurusamy Sarathy wrote:
> On Sun, 04 Mar 2001 18:49:21 PST, Gurusamy Sarathy wrote:
> >The leak is coming from the fact that the anonymous CV prototype created
> >at compile time (and subsequently used for cloning at run time) is never
> >freed.  I think eval"" and its variants should set up an array that
> >accumulates all new anonymous CV prototypes and clear this array after
> >the eval-ed text has finished running.
> Having looked at it some more, I take that back--forget I said it.

Yes - the test case doesn't go near eval, so I didn't think it could be

> The problem really is that there is a reference loop.  The prototype
> anonymous sub holds a reference count on the outer sub via CvOUTSIDE().
> The outer sub holds a reference count on the anonymous sub prototype
> via the pad entry allocated by OP_ANONCODE.  The pad entry will be
> properly freed by op_clear() if it ever gets there, which it doesn't
> because of the loop.

Now that *does* make sense.  Here is the point in Perl_start_subparse()
where everything goes to pot:

    CvOUTSIDE(PL_compcv) = (CV*)SvREFCNT_inc(outsidecv);

After this point, the refcount of of outsidecv is 2, so when it comes to
time to delete it, the refcount drops to 1 only, and nothing happens. 
Now I see how that because of its grip on its outer scope, that in turn
doesn't get freed either, and you get a deluge of leaks.

> We simply need to find a reasonable way to break the loop.  The
> attached (highly experimental) patch does that and appears to cure
> the leak, but makes lib/safe{1,2}.t coredump.  I mean to look into
> it further a little later.

The question I have is does the SvREFCNT_inc(outsidecv) have to happen
anyway in the case of an anon sub?   It will disappear if its outer
scope disappears, so why does it need to increment the outer scopes
refcount at all?  I'm thinking of the changes that were made to break
the stash refcount loop, where the element of the stash had a refcounted
handle back to its parent - the fix there was just to not increment the
refcount, on the basis that the child couldn't exist without the parent
anyway.  I can see that named subs *would* have to increment the
refcount of the outer scope, because they are entries in a stash and can
therefore exist after the scope that created them disappeared.

Alan Burlison

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