oops, corrupted memory again!

[Richard Harter]

In article <> faustus at cad.UUCP (Wayne A. Christopher) writes:
>In article <4495 at cbrma.UUCP>, trl at cbrma.UUCP (Tom Lanning) writes:
>
>> 	Are there any "malloc" routines that check for modification of
>> malloc's link pointers by the "user's" code?   Close to 70% of by bugs
>> are stack/memory problems were I use more space than I allocated.
>
>You could compile the 4.3 malloc() with the -DRCHECK flag, which checks
>that you haven't modified the areas beyond your segment when you free it.
>Also, if you're REALLY paranoid, write your own malloc that puts lots of
>padding around the allocated areas and checks that none of the padding
>areas has been changed every time you call malloc() or free(). 
>
	We wrote our own, partly out of paranoia an partly out of a 
probably misguided belief that we could write a more efficient allocator.
The main thing that we did was to put all pointers and links in an entirely
separate area from the space being allocated.  This wins in that pointers
never get overwritten -- it loses in that the program does not crash 
immediately on range errors.  We added a one word pad on each end for
overwrite testing (can be turned off) and legitimacy tests on all returns
of space.   We also put in a option to store where requests were coming
from.  (Hasn't been used in years.)  The upshot is that space request/free
problems are rare and easily found.  However this doesn't avoid the problem
of incorrectly dimensioned arrays which are handled by the system and can
lead to very peculiar bugs.

		Richard Harter, SMDS Inc.