in reply to Re (tilly) 1: any way to control a memory leak
in thread any way to control a memory leak

I would like to try your code out but am a little confused on how to use it? below is an oversimplification of code I am using for debuging? how would I implement your example in this case. Thanks Robert
#!/bin/perl use strict 'vars'; use Utils; while(1){ my $utlp = new Utils(); $utlp->connect(); $utlp->Log("database connected.\n"); $utlp->disconnect(); $utlp->Log("database disconnected.\n"); sleep(5); }

Replies are listed 'Best First'.
Re (tilly) 3: any way to control a memory leak
by tilly (Archbishop) on Jan 28, 2002 at 20:51 UTC
    I would suggest starting with Devel::Leak. What I offered is mostly for use once you know that you are leaking Perl objects, in a class without a DESTROY, and you need to figure out where. In which case I would use it like this:
    #!/bin/perl use strict 'vars'; use Leaker; use Utils; %Leaker::CLASS = (); while(1){ Leaker::Leaked(); %Leaker::CLASS = (); my $utlp = new Utils(); $utlp->connect(); $utlp->Log("database connected.\n"); $utlp->disconnect(); $utlp->Log("database disconnected.\n"); sleep(5); }
    And then I would run setting different filters in the logging done in the overidden bless in Leaker to narrow things down.

    It won't work if the leaked things aren't objects, if they are created at an XS level, or if they have their own DESTROY method. (It would be possible to hack around the latter issue with some Perl wizardry, and I pointed you at example source-code you could find the necessary technique in.)

    For me it was useful because I was leaking a big complicated object which had lots of other objects in it. I didn't care to know details about all of the components, I just wanted to figure out why the base object was not going away. It may or may not be useful for you.

    I would recommend trying Devel::Leak first.