Messages in this thread |  | | Date | Tue, 28 Jan 1997 16:11:25 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: Memory allocation errors |
| |
On Tue, 28 Jan 1997, David Schwartz wrote:
> > You made some sense up until here: > > On Tue, 28 Jan 1997, Richard B. Johnson wrote: > > > If memory isn't freed, here's another "denial of services" ... > > Any DOS attack could just as easily not call 'free'.
I am NOT talking about DOS. Look at the libc-5.3.12/libc/malloc/free.c and the rest of its family. An attempt is made to return RAM to the system. However, the code has at least one BUG so that the conditions necessary to perform this simple operation never occur.
/* Now see if we can return stuff to the system. */ blocks = _heapinfo[block].free.size; if (blocks >= FINAL_FREE_BLOCKS && block + blocks == _heaplimit && (*__morecore) (0) == ADDRESS (block + blocks)) { register size_t bytes = blocks * BLOCKSIZE; _heaplimit -= blocks; (*__morecore) (-bytes); _heapinfo[_heapinfo[block].free.prev].free.next = _heapinfo[block].free.next; _heapinfo[_heapinfo[block].free.next].free.prev = _heapinfo[block].free.prev; block = _heapinfo[block].free.prev; --_chunks_free; _bytes_free -= bytes; }
Now, I don't have a later version of this runtime library and it is possible that it has been fixed.
> > A general purpose malloc/free pair that allocates memory out of a > single linear pool should never try to shrink that pool.
Tell me where "it" says this?? FYI many database servers attempt to allocate as much memory as possible so that as much of the database as possible reside in memory. After the "transaction", data are written, buffers freed, then a sort/merge program executes. This also tries to allocate as much memory as possible, etc. If the first deallocation did not succed, the second program will fail to allocate its needed RAM. This is exceedingly common and standard...
> Only a > malloc/free pair for programs that can expect to benefit from this > behavior should use it. > > If you need large transient buffers that need to be returned, you > MUST allocate them from their own pool so that the whole pool can be > returned to the operating system. mmap/munmap do this. malloc/free do not > and can not.
The present runtime library does not, but it should and must.
Cheers, Dick Johnson -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard B. Johnson Project Engineer Analogic Corporation Voice : (508) 977-3000 ext. 3754 Fax : (508) 532-6097 Modem : (508) 977-6870 Ftp : ftp@boneserver.analogic.com Email : rjohnson@analogic.com, johnson@analogic.com Penguin : Linux version 2.1.23 on an i586 machine (66.15 BogoMips). Warning : It's hard to remain at the trailing edge of technology. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
|  |