No subject

From: <bogus_at_does.not.exist.com>
Date: Sun Feb 27 13:22:22 2005

manage fragmentation of memory very badly, and I'd venture to guess that's
probably at least part of the problem. The problem is simple: you do two
malloc()s each requesting 48 bytes. Sometime later, one of the blocks is
free()d. Sometime after that, the second block is free()d. If the runtime
library is at all good, it will rejoin the two adjacent small blocks to a
single larger (96 byte in this case) free block. If it doesn't do this,
then free memory becomes a list of small, adjacent free blocks, and memory
requests for larger blocks have to be taken from memory not previously
allocated. This can exhaust system memory rapidly, particularly in
applications that rapidly allocate and deallocate data that is variable in
site (like perhaps, a struct that contains an allocated string or byte
buffer). This is easily fixed by writing a malloc() that free()s well, and
I have code for such a beast if you'd like it.

Of course, it could also be that your program has a small leak. This is
easily detected in a debug_malloc()... increment a counter on malloc(),
decrement on free(), and print the value of the counter when your program
exists. Expect zero if everything allocated was deallocated. Greater than
zero indicates a leak, and a leak in combination with fragmentation can be
lethal. Less than zero indicates that a block was free()d more than once,
which is a highway to pointer problems and random crashes. Here's where a
wrapper falls short, however: wrapping only replaces the calls in your
program; any place the underlying runtime uses malloc() will still use
malloc(), so a runtime function that fails to free() takes more work to
detect. sprintf() and its variants are good suspects: they often need small
amounts of temporary string space during formatting, so while they don't
outwardly allocate memory, they can be busily doing it (perhaps badly)
behind the scenes.

Can you tell I love this stuff?! :-)
Patrick
Received on Sun Feb 27 2005 - 13:22:22 GMT