Detecting Memory Leaks

[gaf at blu.org (Jerry Feldman)]

On Fri, 16 Jul 2004 10:02:00 -0400
Robert L Krawitz <rlk at alum.mit.edu> wrote:

> I think glibc does, at least on Linux -- I've seen process sizes
> shrink as well as grow.  However, it can only return full pages back
> to the OS.  So if your application is fragmenting its heap, it may
> become less and less able to return pages like this, even if it's not
> actually leaking memory.
You might be correct. The problem with returning memory is that the
allocations must be clean, especially if sbrk(2) is used to allocate the
pages. Some mallocs are using an arena technology by using mmap(2)
either in conjunction with sbrk(2) or independent of it. 
The allocator must make sure that when returning memory back, that it
must be from top down (when using sbrk(2)). One of the advantages of
using mmap(2) is that mmap(2) can allocate pages anywhere in virtual
memory where sbrk(2) only allocates from the top of the heap. 
-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20040716/1497d832/attachment.sig>