Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Detecting Memory Leaks

On Fri, 16 Jul 2004 10:02:00 -0400
Robert L Krawitz <rlk at> 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>
Boston Linux and Unix user group 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: <>

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /