gordon@sneaky.UUCP (06/22/86)
> Keywords: malloc, brk > Summary: beware of stdio doing malloc behind your back > 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.) [ detail deleted ] > 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. I think there's a better way to handle this. On 4.1bsd and Xenix/68000 Version 3, and probably v7 also, malloc does not have its own idea of "top of memory". It has its own idea of "memory assigned to malloc", which is not a single number. If malloc needs more memory, it tries to get a chunk from sbrk(), possibly more than was requested, and it keeps track of that chunk. It doesn't assume that that chunk is contiguous with the previous one it got, and user calls to sbrk() don't get in the way of malloc, or vice versa, UNLESS the user program makes the assumption that it can free something it allocated with sbrk() (and, along the way, everything past it) by calling brk() or sbrk() with a negative argument. You can still get the same performance: if malloc allocates large chunks and hands out individual small pieces, it can avoid one system call per malloc. sbrk() isn't really a system call, and sbrk's idea of where the end of memory is is kept in the user data area. Xenix/68000 V 3 has this problem with a feature called "shared data", which grows the data segment without telling sbrk() about it. Guess what happens if you mix shared data and malloc()? Also, guess what happens if you accidentally write on sbrk()'s hidden variable? > > Dave Cornutt > Gould Computer Systems > Ft. Lauderdale, FL > Gordon Burditt ...!convex!ctvax!trsvax!sneaky!gordon