🚀 go-pugleaf

I have tested a software package called "Purify" and would like to
tell you about it.  Purify modifies your object code to check all
memory references for

	1.  Access errors, e.g., reading uninitialized memory,
	access to freed memory blocks and reading/writing past
	the end of an array.

	2.  Memory leaks, i.e., memory blocks that are not
	reachable through something that looks like a pointer.

This list covers a fair number of common C++ programming errors, and
the information from Purify is really helpful in finding the causes.
The drawback is primarily that the execution speed doubles, so this is
really a development tool.

I have used Purify on a rather large application that uses IV 2.6 --
sorry, we haven't upgraded to 3.0.1 yet.  I will not get into details
about the errors we found, but here is an overview.

(a)  We found some plain bugs in our own code, for example, that we
took the address of a local variable and passed it to a function that
eventually called `delete' on that pointer.

(b)  A very common error is that Transformer::operator= reads and
writes memory that has been returned by calling `delete'.  This is bad
news because those blocks may be reallocated by some other part of the
application (Purify keeps deallocated blocks around for a while to
check this).  I haven't had time to find the cause of this bug.

(c)  Font::Width reads beyond the end of the allocated string.  I
haven't pin-pointed the cause, but I have only observed it for labels
in the "graphic" library.

(d)  There are lots and lots of little memory leaks in IV 2.6 (the big
ones were in our application...).  Many of those leaks are the result
of programming errors in our application -- the classical problem of
who takes responsibility for deallocation.  Class `Message' had a
change of semantics quite a while back so it now creates a copy of the
string (which is destroyed, of course).  Our program has some old code
that still `new'-s a string every time it creates a `Message', and
those copies are lost.  The problem is perhaps not the amount of lost
(virtual) memory, but rather the amount of fragmentation caused by
several hundred lost blocks.

So, this was a partial summary of the memory related problems we found
in one application using IV.  I should at this point stress that I do
*NOT* think IV 2.6 is a bad software package; this is not a long list
considering the size and complexity of IV, and as pointed out above,
many of the problems we found are the result of improper use of IV.
(Note that our code is not worse than the average, IMHO.)

As you can tell, I'm very satisfied with Purify, and the problems we
found would have been very difficult indeed to find without this tool,
or something similar.  

I suggest that you contact "info@pure.com" if you are interested in
more information about Purify; if you have questions on what I have
written above, please follow up on the net.  Purify currently only
runs on SparcStation with SunOS 4.1; I think the price is reasonable
(you should get this info from the vendor), and there is a special
price for educational institutions.  We got a free evaluation copy for
two weeks.

Please note that I'm not affiliated with the vendor or anyone selling
Purify -- I'm just a very happy user.

Dag Bruck
--
Department of Automatic Control		E-mail: dag@control.lth.se
Lund Institute of Technology
P. O. Box 118				Phone:	+46 46-104287
S-221 00 Lund, SWEDEN			Fax:    +46 46-138118