in reply to Memory leak when using hash 'references'

If I remember this correctly, and assuming it's the system reports of free memory you're watching, you can't release memory that's been allocated to an application back to the system until the process itself terminates.

The memory you're saving will be freed up, but it will only be available to the Perl process that's running the script until it either performs an exec and terminates, or exits normally.

This isn't actually a memory leak in Perl - it's just how the system itself handles memory management.

Hope that helps ..
-- Foxcub
A friend is someone who can see straight through you, yet still enjoy the view. (Anon)

UPDATE: Clarifications.

Replies are listed 'Best First'.
Re: Re: Memory leak when using hash 'references'
by sureshr (Beadle) on Mar 13, 2003 at 15:20 UTC
    I would have assumed so, provided if the memory continued to stay at a peak value. Instead, I am seeing that a memory of few kbs being freed every now and then and a continual increase in the memory (in Mbs), though my application is no longer sucking in any data.
    My appln sucks in data to an internal Q and processes them later, which is why there is increase in term of Mbs. But after every batch of processing, I free up the whole memory I had used, which should eventually result in 'free memory' in the interpreter's space. But the observation is that the memory increase is steady, which I would expect to be at a steady state atleast. This basically concerns me that Perl is not using up 'its free' memory, before requesting for more :(
    -sureshr
[reply]
      I'm not sure if this is the case, but don't forget that Perl doesn't destroy anything until all references to it are either destroyed or undefed.

      To free up the memory associated with the data, and release it back to Perl, you need to make sure that you also set the original variables that store the data to be undef, and ensure you have no other references to that item that could be keeping it defined.

      Just thinking about scoping, both of the variables you undef in your subs are localised with my anyway, and hence will be automatically destroyed when that sub finishes executing.

      I can't really say any more than that without seeing more code - I'd suggest first to check for references to the data that could be keeping it defined in memory.

      Hope that helps ..
      -- Foxcub
      A friend is someone who can see straight through you, yet still enjoy the view. (Anon)

[reply]
[d/l]
[select]
        Thank you Foxcub, I will revisit all my code to see if there are any dangling references (seems like I could no longer rely on 'my' to free up memory for me, in case of references) and undef them.
        -sureshr
[reply]
Re: Re: Memory leak when using hash 'references'
by Anonymous Monk on May 05, 2003 at 05:28 UTC
    I am not a guru on OSes but I didn't think that was the case, or services like ftp, apache and mysql could consume a system within hours. I wrote a very simple c++ program: 
    #include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

void main (void )

{

        int *a[10000];

        long c = 0;
        do
        {
                a[c] = new int[1000] ;

        }
        while ( c++ < 10001 );

        c = 0;
        do
        {
                delete a[c];
        }
        while ( c++ < 10001 );

        sleep( 20 );
}

    [download]
    the above program gives back the memory to the system, and top shows no abnormal memory usage. Removing the second loop results in an approxmiately 40MB memory usage.

    I tested this on Redhat 7.3 (2.4.18-3) gcc version 2.96 20000731

    edited: Mon May 5 14:02:53 2003 by jeffa - code tags

[reply]
[d/l]
      services like ftp, apache and mysql could consume a system within hours

      Don't each of those re-exec themselves every time a request is made to them to stop that from happening? The way I understand it, an incoming request uses the existing server, and a second, new server process is forked off to await the next request. That initial process is then free to exit once the request is complete, releasing any resources it was holding. Admittedly, my OS knowledge is fairly basic (stuff from Uni, and from my own personal interest), but I'm sure I've read that somewhere *grins*.

      the above program gives back the memory to the system, and top shows no abnormal memory usage

      Gives memory back to the system how? Can you provide some specifics (numeric data as to what's going on, including the name of the field you're looking at in top?) A loop wouldn't (necessarily) use a large amount of memory in its own right; it'd be interesting to get a better idea of what's going on.

      -- Foxcub
      A friend is someone who can see straight through you, yet still enjoy the view. (Anon)

[reply]
[d/l]

In Section Seekers of Perl Wisdom