in reply to Re^3: Memory leak
in thread Memory leak

Maybe the following will help (and yes im pretty sure this is at least part of the reason for his leak):

#!perl -l sub F { my $foo=bless[]; print "create:$foo"; sub T { print "T"; push @$foo,"test"; } print "F"; push @$foo,"bar"; } sub DESTROY { print "destroy: @_:@{$_[0]}" } F; T; T; T; F; __END__ create:main=ARRAY(0x15d53d8) F T T T create:main=ARRAY(0x1a4550c) F destroy: main=ARRAY(0x1a4550c):bar destroy: main=ARRAY(0x15d53d8):bar test test test

T only once shares the same $foo with F, right at the beginning. The first time the sub executes it binds T as a closure to the original $foo and never rebinds it. And since T contains a reference to that $foo, and because T exists in the package table $foo wont be freed until T is destroyed causing $foo's refcount to drop. Thus the OP probably has a number of vars that are filling up without his knowledge behind the scenes. When the inner sub is anonymous, the compiler knows that the closure must be re-resolved each time.

---
demerphq

Replies are listed 'Best First'.
Re^5: Memory leak
by BrowserUk (Patriarch) on Jan 14, 2005 at 10:12 UTC

    Thanks demerphq. I vaguely remembered reading an explanation of this a long time ago, but not where, nor any of the details. That explains it nicely.

    When I saw the "won't stay shared" warnings, saw that several of them related to arrays, and then looked inside and saw that several of the subroutines in question are being used within or from Tk UI callbacks, which tend to gets cycles many times, the alarm bells rang.

    It wasn't possible to actual do anything useful with the program to verify the notion, as it requires soecial format files.


    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.