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, greerga@circlemud.org | Genius may have its limitations, but
http://mouse.van.ml.org/ (mostly) | stupidity is not thus handicapped.
http://www.van.ml.org/CircleMUD/ | -- Elbert Hubbard
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST