using malloc and brk: something to watch out for

[Dave Cornutt]

Keywords: malloc, brk
Summary: beware of stdio doing malloc behind your back
Line eater: uh-huh

If you want to use brk() or sbrk() to do memory allocation, there is
something you have to keep in mind: the standard I/O library does
mallocs to allocate buffers for files that it handles.  The problem
is that, at least on our system (UTX/32, a 4.2BSD derivative), malloc
maintains its own notion of where the top of memory is, and it doesn't
know about brk or sbrk calls done external to it.  (Actually, this makes
sense from a performance standpoint: if malloc had to check the actual
top of memory, that would mean a system call for every malloc.)

What happens is this: say you use sbrk to allocate space at the top of
memory for something (like a indeterminately large array).  You do some
stuff in this space, and then you do some printf's or scanf's on some
file (or some stdio operation, like puts/gets, putc/getc, etc.)  If
the printf/whatever is the first I/O operation done on that file, stdio
will malloc a buffer for it at that time.  Since malloc thinks that the
top of memory is still where it was originally, it will happily allocate
a hunk of your array and let stdio scribble on it.  I ran into this
problem a few months ago, and you would not believe the amount of time
we spent running CPU and memory diags because of it.

The moral of the story is this: (1) once you have done a brk or sbrk,
don't do any mallocs, and (2) if you use stdio and brk/sbrk in a
program together, make sure that all files being handled by stdio have
buffers allocated to them prior to doing any brk/sbrk by either
doing I/O on them (which forces a buffer to be allocated), or by
calling setbuf() to explicitly allocate a buffer (alternatively,
you can set it to unbuffered, although this usually hurts performance).
Don't forget about stdin/out/err.

Now for the flame: There should be some way to confine malloc to a certain
heap space by setting an upper limit on how high it can allocate memory.
This way, the programmer could use malloc and still have clear memory
above the top of the heap space.

Dave Cornutt
Gould Computer Systems 
Ft. Lauderdale, FL

"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."