Re^4: How can I free the memory of a XML::Simple-Object

[Bauldric]

in reply to Re^3: How can I free the memory of a XML::Simple-Object
in thread How can I free the memory of a XML::Simple-Object

You are really great :-) By the way. Do you know a good Package for searching memory leaks under Windows XP and perl version 5.8.8. I have memory problems, although I use allways strict.pm (working only with local vars 'me $var') and have no global vars. The program has about 40000 Lines in 100 packages. I would like to have something like the symdump does to produce a list of all variables whose size has changed or are new allocated between two program-positions:

   my $memdump = MemoryDump->new();

   anyFunction();

   print $memdump->diff(MemoryDump->new();

Exist something like that for ActiveState-Perl?

For your example which you've wrote for me: So if I set the size of the array @a

my @a = ();

$#a = 1e6;

the memory will be used again

my @a = ();

$#a = 1e6;

mem(1);

$a[ $_ ] = $_ for 1 .. 1e6;

mem(2);

undef @a;

mem(3);

my @a = ();
$#a = 1e6;

$a[ $_ ] = $_ for 1 .. 1e6;

mem(4);

sub mem {
    my $mem = `tasklist /nh /fi "PID eq $$"`;
    $mem =~ tr[ \t\n][   ]s;
    print "$mem : $_[0]\n";
};

[BrowserUk]

Exist something like that for ActiveState-Perl?

See Devel::Size & Devel::Size::Report which does/can do something similar.

(I also just noticed Devel::SizeMe which I've no knowledge of, but comes from a good author, so would be worth investigating.)

I have to admit that I rarely resort to such tools for tracking memory leaks. Especially if threads are involved; I have my own method.

Basically this involves commenting out the bodies of suspect subroutines/methods -- but having them return plausibly 'good' values -- one at a time until I find which one is contributing to the leak. Then zeroing in from there.

With a program as complex as yours, it could be quite a laborious process, but I find it quicker than wading through reams of dumps. Especially where threads are involved which usually forces you to have to cross-relate data from several threads.

Working out which thread (type) is the cause is often quite easy. Just run an empty(ish) thread procedure for each type -- that again does just enough by way of modifying shared data or returning plausible values to allow the program as a whole to continue to run.

Once you've isolated the thread type involved, then apply the function-by-function mechanism as you would for a single threaded app.

It is actually harder to describe than do.

Good luck. (FV?)

[bulk88]

I have found that for CVs/subs Devel::Size will count entire package/class (GVs and every slice in the GV and all the shared key names of the stash and all sub stashes) that a CV is in for the size of a single sub. An XSUB with no optree comes in at a dozen KB. Be careful of what Devel::Size tells you.

[BrowserUk]

Indeed. For tracking absolute sizes, that can be a problem.

But for the purposes of tracing leaks, whether they are optimistic or pessimistic for any particular construct, so long as the measurements are consistent, then the purpose is well served.