AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
October 2006

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2006.10.25 08:48 "Newbie Question on Memory Usage within LibTiff", by Amarnath S
2006.10.25 09:21 "Re: Newbie Question on Memory Usage within LibTiff", by Joris Van Damme
2006.10.25 15:33 "Re: Newbie Question on Memory Usage within LibTiff", by Edward Lam
2006.10.25 11:49 "Re: Newbie Question on Memory Usage within LibTiff", by Gerben Vos
2006.10.25 16:00 "Re: Newbie Question on Memory Usage within LibTiff", by Bob Friesenhahn

2006.10.25 16:00 "Re: Newbie Question on Memory Usage within LibTiff", by Bob Friesenhahn

On Wed, 25 Oct 2006, Amarnath S wrote:

> Hi,
>
>    I am a newcomer to LibTiff, and to TIFF in general; this question
> relates to memory usage in the TIFF library. I have a simple C program to
> create a TIFF file (modified slightly from its original, available on
> www.stillhq.com). I ran it on Visual C++ 6.0. At the line marked AAAA in the
> code, the memory usage was 1404 K, whereas at BBBB, it was 1516 K (as
> monitored on the Windows Task Manager); this means that there is a memory
> leak somewhere. I am using Windows XP SP2. The entire C program is given
> below.

Note that the term "leak" implies that if the same code path is 
executed again, additional memory (and probably of similar proportion) 
will be consumed.  It is not uncommon for libraries to create "static" 
allocations which are allocated only once in the lifetime of the 
program.  This also includes system libraries.  These would appear as 
"leaks" using your method, but are not actual leaks.  A better way to 
prove leaks is to execute the same path 1000 times and see if the 
memory use continues to grow.

The Windows memory allocator is weird in that it reclaims deallocated 
memory on an as-needed or as-convenient basis for use by other 
programs.  This differs from the traditional Unix approach where any 
memory allocated is retained for later use by the program.  However, 
many modern Unix systems use a malloc()/free() implementation which 
does return large allocations to the system by using using memory 
mapping to perform the allocation.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/