From: cpcahil@virtech.uucp (Conor P. Cahill)
Subject: Re: Finding memory-related defects (was: Re: SUMMARY Re: Purify vs dbmalloc)
Organization: Virtual Technologies Inc.
Date: Fri, 9 Oct 1992 11:38:17 GMT

wahl@dickh.enet.dec.com (David Wahl) writes:

>Actually, I've spent quite a few years tracking down such problems through
>inspection and preventing them through judicious application of design and
>coding standards.

If you have spent "quite a few years" tracking down memory problems through
inspection, you are making a great case for using a memory debugging tool.

If, on the other hand, you are saying that in the course of normal code
inspections you have found memory errors, that is one of the things that
is supposed to come out of said inspections.  

None of the alloction debugging tools vendors (atleast, that I know of) are
saying "use our tool and forget about inspections".  What we are saying is
that many of these problems get past even thorough inspections and it is 
therefore prudent to use this kind of tool as an aid to the QA effort.

Of course, the main point to these tools is that they save the developer's
valuable time by reporting the exact location of the errors and trapping 
many errors before they have corrupted the program's context.

>While I agree that the use of such tools is valuable during development, 
>I'm not convinced that they are worth the cost of licensing the run-time 
>for volume shipments of a product.

I'm not sure what you mean by this.  There is no run-time license
requirement for SENTINEL, so as long as you have a license for the 
development system, you can ship as many run-time systems to as many
customers as you like.

>  I'm also concerned about the fact that 
>the system services I depend on (such as certain well-known window systems) 
>are using the basic OS memory allocation routines and not a special library 
>which traps such defects. 

I think this is more an artifact of C rather than the system.  C historically
does not do run-time checking of paramaters and boundaries (which is one
of the reasons why it has good enough performance to be used to implement
an OS).  There is a substantial amount of processing overhead associated
with checking and traping these kinds of defects.

> Also, I want to know that a library which is 
>shipped with my product to do something so basic as memory allocation is 
>ABSOLUTELY free of defects

I doubt there is any non-trivial software that is "ABSOLUTELY" free of
defects.  SENTINEL has found several allocation problems in the standard
libc.a shipped with many systems.

> and won't collide with all the other unexpected
>products operating on the system my customer will use.

The only way that SENTINEL could collide with software outside of the
program that it is linked with is in the following cases:

	1. there was a namespace collision with respect to environment
	   variables (SENTINEL starts all of its environment variables 
	   with the token SE_ which makes this less likely.

	2. there is a namespace collision with respect to one of the
	   configuration files.  SENTINEL's configuration files all 
	   have the name sentinel in them which should reduce the likelihood
	   of this occurring.

	3. Error reports are sent to the wrong place (you have full control
	   of where error reports are sent, so I don't consider this a
	   problem).

Otherwise, there is no interaction with the outside world.  I think
it somewhat unlikely that the use of SENTINEL will cause one of your
programs to collide with other unexpected products on your customer's
system.
	   
-- 
*** SENTINEL(tm) The ultimate Debugging Environment - email for more info ***

Conor P. Cahill              (703)430-9247            cpcahil@virtech.vti.com
Virtual Technologies, Inc.  46030 Manekin Plaza          Dulles, VA 20166 
Newsgroups: comp.software-eng