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

When I had to deal with a problem like this I found the information from Devel::Leak rather useful. For tracking down objects I hacked up something like this to use to find where I was allocating objects that never went away:

package Leaker;
use Data::Dumper;
$Data::Dumper::Indent = 1;
%CLASS;

*CORE::GLOBAL::bless = sub {
  my $obj = shift;
  my $class = shift || caller();
  if (exists $CLASS{$obj}) {
    delete $CLASS{$obj};
  }
  $obj = CORE::bless($obj, $class);
  if ($class =~ /ObjClass/ or (caller())[1] =~ /file|names|here/) {
#    print "$obj created\n";
    $CLASS{$obj} = join "\n\t", map {join ":", caller($_)} 1;
  }
  $obj;
};

sub UNIVERSAL::DESTROY {
  my $obj = shift;
  if (exists $CLASS{$obj}) {
#    print "$obj destroyed\n";
    delete $CLASS{$obj};
  }
}

sub Leaked {
  print Dumper(\%CLASS);
}

1;
[download]

It worked for me. That won't work for classes which have a DESTROY method of their own. (You could just choose to replace those methods on the fly with a wrapper, much like Dominus does with Memoize.) That also won't help much if your memory leak is at the C level. (Which it well could be.)

If all else fails you can just restart yourself with:

exec($0, @ARGV);
[download]

But personally I would be strongly inclined to have the process hold a lock while it is running, and then have a periodic cron job that starts the job if it is not currently running. A big advantage of that approach is that if you have an unexpected shutdown of the process (eg a machine reboot) then nobody has to remember to start your process again. (This is a classic Unix mistake. Someone writes a daemon that is key to their process, launches it, doesn't document, then 6 months later there is a reboot and nobody knows how to get it running again.)

Comment on Re (tilly) 1: any way to control a memory leak Select or Download Code

Replies are listed 'Best First'.
Re: Re (tilly) 1: any way to control a memory leak by rdww (Novice) on Jan 28, 2002 at 20:19 UTC
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); }` [download]	[reply] [d/l]
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); }` [download] 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.	[reply] [d/l]