memory allocation problems

[Paul Hays]

In article <11589 at arctic.nprdc.navy.mil> asbury at nprdc.navy.mil (Mike Asbury) writes:
>HELP!  I have a large program (over 100,000 lines of code) written in Turbo C
>with memory leakage somewhere.  I am looking for any programs that will help me 
>find C memory allocation errors.  Any pointers to shareware or commercial 
>programs will be appreciated.  
>					Thanks in advance,
>					Mike

In article <1991Jan18.000814.15191 at watdragon.waterloo.edu> rwskubowius at spurge.uwaterloo.ca (Rog Skubowius) writes:
>
>	               ...            I encourage you to write 3 ( or
>	possibly 6 ) routines, 1 per C dynamic function routine. For
>	instance, CheckMalloc(), CheckFree(), CheckRealloc(). If you
>	use a prefixing ( & possibly postfixing ) signature on the allocated
                        ^^^^^^^^ ^^^^^^^^^^
Always: many arena corruptors seem to scribble on the upper signature.

>	buffer, & embed the buffer size as well, you can easily fix this
>	problem & find the bug. Let me show this:
>
>	unsigned short CheckMalloc( void ** buffer, unsigned short size )
>	{
>		The application on top of CheckMalloc() wants 'size' bytes,
>		but instead, now call malloc() for 'size' + say 3. Then, write

The number of additional bytes is critical in some applications;
the buffer must be aligned on many mahines.

>		the letters 'foo' in the first 3 bytes of the allocated memory
>		& assign (*buffer) to the next byte following the 'foo' signature.
>
>		fooXXXXXXXXX	-> where a pointer to the 1st X is returned 
>						-> through (*buffer) to the calling function.
>
>	}
>
>	void CheckFree( void * buffer )
>	{
>		Now, if the application has corrupted the buffer, you can
>		determine it here. You see, *(buffer - 3) == 'f', 
>		*(buffer - 2) == 'o', *(buffer - 1) == 'o'. You should really
>		macro the checking signature, its length and then use 
>		strncpy() to do the checking of signature. Anyway, if this
>		doesn't check out...bang...you've caught some memory corruption
>		as either the original 'CheckMalloc()'d pointer was moved, or
>		someone overwrote part of your buffer.
>	}
    [etc.]

We use a shell around the malloc() routine as well; mine is specified
to match the C library routine with additional side effects:
    - The allocator returns a 'char *' (hey, it's pre-ANSI).
    - The signature below the returned address is large enough to
      ensure that the address is suitably aligned for an object
      of any type. (This 8 bytes for the RISC machines.)
    - The allocator saves information used for automatic checking.

This code is only linked into development versions of the programs
because of the overhead (see below). For the release version, the
C preprocessor is used to substitute the actual C library routines:
    #define mallocph(s) malloc(s)    /* use C library allocator */

These routines get very serious about detecting corruption of the
arena. The module that defines the checking routines also defines
a large static array of structs used to track the
status of each block allocated. Each block gets
a serial number that is recorded in its struct, along with the block's
size and address. (The checking routines keep only 'signature' bytes
in the allocated space; everything else is in the array. After all,
we're looking for arena corrupters ...)

Whenever any block is allocated, reallocated, or freed, an internal
routine scans the static array and checks all of the signatures
at the bottom and top of each block.

It seems that many corruptors call the routines strcat(), strncpy(),
memset(), memcpy(), and the like to scribble on the arena for them.
The latest incarnation of the checker includes shells for these
routines as well; the shell routines call the C library routine
and then test to see whether it misbehaved.

Amazingly, the overhead for all of this checking has not proven to
be a problem even in programs which use the arena excessively.
-- 
Paul Hays                Cognos Incorporated     S-mail: P.O. Box 9707
Voice: (613) 738-1338 ext 3804                           3755 Riverside Drive 
  FAX: (613) 738-0002                                    Ottawa, Ontario 
 uucp: uunet!mitel!cunews!cognos!paulh                   CANADA  K1G 3Z4