lkml.org 
[lkml]   [1997]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectMemory allocation errors
Date

Richard B. Johnson wrote:
> From info received here, I decided to make my own check of a
> possible memory allocation bug. I can confirm that the bug does,
> indeed, exist.

Not a bug!

malloc() and free() are library funcs, not system calls.

malloc() may sbrk() up the data segment to get more memory,
but not all implementations of free() will sbrk() down. Therefore
free()d memory will not be returned to the OS, but will stay in a
process's address space.
For malloc engines which use sbrk() and can return memory to the
system, the conditions which allow this are limited.

If you need to allocate/free a large block of memory, and have it
returned to the system, mmap()/unmap() anonymous memory.

> I can run the first program forever on my Sun (SunOS 5.5.1). This
> machine, in spite of its many problems, does deallocate RAM when
> free() is called.

It is possible to write malloc()/free() to use mmap()/unmap(), maybe
SunOS 5.5.1 does this (but then again, maybe not).

Regards,

markhe

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.029 / U:4.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site