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.)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;
If all else fails you can just restart yourself with:
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.)exec($0, @ARGV);
In reply to Re (tilly) 1: any way to control a memory leak
by tilly
in thread any way to control a memory leak
by rdww
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |