Re: Incredibly Strange Bug

From: George (greerga@CIRCLEMUD.ORG)
Date: 09/13/98

On Sun, 13 Sep 1998, James Turner wrote:

>Generally (at least on Linux systems), if you get a crash in a
>malloc/free/realloc, and the params are sane (legit sizes, valid
>pointers), then the problem is usually overwriting/underwriting a
>malloced region of memory.  Why would that mess up a later malloc or
>free on a different block of memory?  Answer below!

MALLOC_CHECK_=1 bin/circle

>What I've done with my code is added functions (mud_free, mud_malloc,
>mud_calloc, mud_realloc) that use their own magic byte scheme.  This
>helps check for allocation problems etc.  Basically I allocate 8 bytes
>extra, store the size at -4bytes and again at N bytes, then
>periodically check it to be valid.  I almost backended into malloc's
>data, but that is tremendously system specific (not to mention
>painful, as malloc is somewhat complicated).  Down side: 8 bytes per
>alloc lost (and this can be a lot, as my mud averaged 55,000 unfree'd
>mallocs at any one time, in about 5,000,000 bytes).

I find the above method, built into malloc, works a lot better and doesn't
crash(*) either.  If you _do_ want it to abort() when it finds bad memory,
use 'MALLOC_CHECK_=2 bin/circle'. Above 2 doesn't do anything.

(*) - Well, as well as you can expect it not to crash after you've munged
memory beyond hope.

George Greer, | Genius may have its limitations, but   (mostly) | stupidity is not thus handicapped.    |                  -- Elbert Hubbard

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST