Memory size growing by 4 bytes each iteration of only 11 iterations is pretty scanty evidence of a leak. Perhaps you only posted a minimal test case and you have a larger test case that shows that the leak continues. But it is perfectly reasonable for the above code to grow slightly in memory size until things "settle in".

In contrast, this code:

sub test {
    $_[0]= 'foo';
}
while( 1 ) {
    test();
}
[download]

A more reasonable test case for you to work with might be:

sub test {
    $_[0]= 'foo';
}
while( 1 ) {
    for(1..1024) {
        test();
    }
    sleep( 1 );
}
[download]

Hey there Tye, obviously this is a very contrived exapmle, and not something that I would necessarily do, however i'm trying to get to the bottom of a perl CORBA memory problem (in COPE) that may be casued by something similar to the above example. I didn't post my CORBA code as it only muddies the water and is too large. Using the while loop as you have suggested still increases by 4 bytes (in both cases). Thanks for the feedback on Perl 5.6.0 - an upgrade may be an option. I don't follow your 'settling in' argument. Why is memory not freed for a string 'foo' assignment, but is freed for a number asignment ? Cheers Mike

Using the while loop as you have suggested still increases by 4 bytes (in both cases).

Do you mean it increase by 4 bytes once, or every single time it goes through the loop?

I don't follow your 'settling in' argument.

Perl need a certain amount of memory to do what you asked for. Taking that amount is not a "leak" but just the normal process of running a program. After allocating enough memory, the program should "settle in" and not need to get more unless your data grows.

On the other hand, if the program grows constantly when you aren't adding any data, that would be a leak. If it really leaks, you should be able to run that loop tye posted until it consumes all the memory on your machine and goes into swap.

Why is memory not freed for a string 'foo' assignment, but is freed for a number asignment ?

Because numbers are fixed length and so fit directly into the SV struct while strings are variable length and so are separately malloc()ed with a pointer stored in the SV struct.

I'm a bit surprised that it only grows by 4 bytes. It would be a bit interesting to make the string slightly longer and see how many bytes get added per iteration.

But if upgrading Perl just makes the problem go away, then someone probably already ran down this particular bug and so repeating their work probably isn't worthwhile.

Perhaps a long shot, but there was also a problem where certain types of temporary values were not free until a loop was exitted.

        - tye (but my friends call me "Tye")