[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

SMARTALLOC: Orphaned buffer detector

Many of you have encountered various versions of the SMARTALLOC
package, which detects orphaned buffers and other errors in
management of heap storage.  Fewer, less lucky, people have had
the experience of extracting SMARTALLOC from an existing product to 
install it in a new one, discovering that as you pull on it, more
and more pieces come out: here a queue, there a "min()", everywhere
a typedef.

With the intent of adding a SMARTALLOC facility as an optional part
of our ADS library, I've prepared an extracted, cleaned-up, extended,
and reasonably portable version of SMARTALLOC.  Although this code is
derived from the three-year heritage of SMARTALLOC, there's a substantial
amount of new code here, and even though I've exercised it with a dedicated
test program included with the release, you may encounter some problems
wedging it into an existing product.  If so, I'll be glad to help as best
I can.

The master copy is available on Technet in the directory:


and, for a LIMITED TIME, BLUE LIGHT SPECIAL, a distribution version is


in conventional Usenet distribution form, including a README file and a
Makefile for a Sun demo of the package.  If you aren't familiar with "shar"
distribution form, just do a:

	head -20 ~uucp/smartall.shar

to be enlightened.

An overview of SMARTALLOC, extracted from the README file, follows:


Few things are as embarrassing as a program that leaks, yet few errors
are as easy to commit or as  difficult  to  track  down  in  a  large,
complicated   program   as   failure   to  release  allocated  memory.
SMARTALLOC replaces the Unix library memory allocation functions  with
versions that keep track of buffer allocations and releases and report
all orphaned buffers at the end of program  execution.   By  including
this  package  in your program during development and testing, you can
identify code that loses buffers right when it's added and most easily
fixed, rather than as part of a crisis debugging push when the problem
is identified much later in the testing cycle (or even worse, when the
code  is  in  the  hands  of  a  customer).   When  program testing is
complete, simply recompiling with different flags  removes  SMARTALLOC
from  your  program,  permitting  it  to  run without speed or storage
In addition to detecting orphaned buffers, SMARTALLOC  also  helps  to
find  other common problems in management of dynamic storage including
storing before the start or beyond the end  of  an  allocated  buffer,
referencing  data  through  a pointer to a previously released buffer,
attempting to release a buffer twice or releasing storage not obtained
from  the  allocator,  and  assuming  the  initial contents of storage
allocated  by  functions  that  do  not  guarantee  a   known   value.
SMARTALLOC's  checking does not usually add a large amount of overhead
to a program (except for programs which use realloc() extensively; see
below).   SMARTALLOC  focuses on proper storage management rather than
internal consistency of  the  heap  as  checked  by  the  malloc_debug
facility available on some systems.  SMARTALLOC does not conflict with
malloc_debug and both may be used together, if you  wish.   SMARTALLOC
makes  no assumptions regarding the internal structure of the heap and
thus should be compatible with any C language  implementation  of  the
standard Unix memory allocation functions.