Re: Re[2]: 971110: Memory leak question

>To: Russ Rew <address@hidden>
>From: address@hidden
>Subject: Re[2]: 971110: Memory leak question 
>Keywords: 199711101835.LAA26543

John,

>    Thanks for your help.  I used the test program you provided and I seem 
>    to still have memory leaks.  I think I'm using the wrong method for 
>    testing for memory leaks.  I'm using gmemusage and cvd (graphical 
>    version of dbx debugger for the SGI) to see if I have any memory leaks.  
>    I ran your code inside cvd and put breaks before and after the line 
>    containing ofile.close(). At the first break I used gmemusage to see how 
>    much memory your code was using and then I stepped over the 
>    ofile.close() and noticed that no memory was given back to the SGI.  I 
>    even tested you code using one of my 12meg cdf files with the same 
>    results.  Gmemusage could be the wrong tool to test for memory leaks.  
>    What tools or methods do you use to test your results.  Any help would 
>    be appreciated.

I have since gotten a beta copy of "purify" for SunOS 5.6, which is the
tool we use to test for memory leaks.  Running it on the example program
I sent showed no memory leaks.

I think the way you are measuring memory usage will not reveal memory
leaks.  For example, the following small C++ program has no memory leaks,
but your means of testing it might make you think it has a memory leak:

int
main() {
    int *buf = new int[10000];

    buf[500] = 1;
    delete [] buf;

    return 0;
}

If you measure the memory usage both before the delete statement and
then after (when the 10000 integers allocated for "buf" have supposedly
been released back to the operating system), you will probably find no
change.  This is because a running C++ program doesn't actually grow and
shrink as memory is allocated and released; instead it keeps freed
memory for use in later memory allocations.  Whenever "new" is invoked,
the "heap" is first checked to see if enough memory is available from
previous deletes to allocate the requested memory there.  Only if that
fails is new memory requested from the system, at which point the heap
grows to accommodate the latest request.  The heap won't shrink however;
that would be very inefficient on most operating systems.

Here's an example of a real memory leak:

int
main() {
    int *buf = new int[10000];

    buf[500] = 1;

    buf = new int[5000];  // oops, previous memory used by buf has leaked
    delete[] buf;

    return 0;
}

In this case the original 10000 ints allocated to buf are never returned
to the heap and can never be used by any other allocation, since the
pointer to that memory was "lost" when buf was reassigned.  The "purify"
tool detects the above memory leak of 40000 bytes and verifies that the
first example has no leaks.

Hope this helps.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu