NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/sources/wanted/5035

Internet Message Format | 1992-11-11 | 5.6 KB

Xref: sparky comp.sources.wanted:5035 comp.software-eng:4263 comp.sys.sun.apps:2462
Newsgroups: comp.sources.wanted,comp.software-eng,comp.sys.sun.apps
Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!csn!raven!rcd
From: [e-mail] (Dick Dunn)
Subject: Re: Purify & Sentinel
Message-ID: <[e-mail]>
Summary: a complaint in the form of a reverse testimonial
Organization: eklektix - Boulder, Colorado
References: <[e-mail]>
Date: Fri, 13 Nov 1992 07:40:39 GMT
Lines: 89

(minor flamage first, but hang in; substance follows)

[e-mail] (Reed Hastings) complains:
>In several recent postings, the developers of Sentinel compared their
>product with standard malloc debug and Purify.
>
>We realize that it is inappropriate for vendors to argue about their
>products on the net...

...but this doesn't stop Hastings from posting another 650 lines of
advertising in three non-commercial newsgroups!  Compare this with Cahill's
recent followup on the Sentinel side, which says briefly "we're sorry; we
probably did overstep the bounds; we think we were fair; for anything more,
use email."  If the Sentinel postings overstepped the bounds, surely a
large, blatant advertisement in reply is worse--especially after admitting
that commercial postings are inappropriate.

Nor is this Hastings' first serious attempt to use a non-commercial venue
for advertising.  See the proceedings of the Winter 1992 USENIX Conference
for Hastings' paper on Purify, which managed to get accepted in spite of
USENIX's traditional stance that vendors are welcome, but thinly-veiled
product announcements are not.  That paper/presentation prompted substantial
complaints--somewhat about lacking detail (set aside to "proprietary tech-
niques", which is roughly the technical equivalent of "executive privi-
lege"), mostly about the major commercial slant.

But that's all a digression...I should be posting technical content, and I
shall do so.  Unfortunately for Hastings, I only have experience with his
Purify product.  I tried it under their limited-time trial-copy offer
(which in itself is a laudable way to offer software).  The overall result
was that, after considerable effort to interpret the output from Purify,
it provided *NO* useful information--none whatsoever!  Herewith, a few
details:

My major test case was one rather large C program.  It's close to 200,000
lines.  It makes extensive use of dynamically allocated memory from half a
dozen modules...and there are cross-references from objects in one module
to objects in another.  Certain classes of errors are recovered with
"longjumps" (C's non-local gotos) which invite stale pointers and memory
leaks.  The program has evolved over about six years and has been adapted
to radical changes in purpose/spec over its lifetime.  In short, it should
be a nightmare, ripe for the sort of checking Purify is supposed to offer.

To be fair to the authors and current maintainers of this program, they're
very good and the management is enlightened (to say the least), so the
techies get to go in with their entropy-chainsaws and clean it up often
enough.  Still, it was a big old program with substantial cruft; it was
healthy but nobody in his right mind would assert that it was free of
memory-handling problems.  In fact, at the point I tried Purify, we *knew*
there were memory leaks and uninitialized data (verified by having fixed
some of them since), and we strongly suspected there were stale pointers.

The first obstacle--which is inherent in the way Purify works; it's both a
strength and a weakness--is that Purify is tied to a particular compiler.
We were using gcc (because multiple platforms and cross-compilation were
essential); I had to rebuild with Sun's cc and shave a bit of hair from
that.  No big deal, but a vulnerable point.

The execution produced enormous amounts of output.  Almost all of it was
spurious complaint, due to Purify's inability to detect the copying of
"holes" in structures (i.e., the empty space left within structures to
satisfy alignment constraints).  These complaints had to be investigated
one at a time, and I had to develop a set of sed/awk scripts to filter them
out.

This left me with a small number of complaints about apparent memory
leakage which, although worth a check, really wasn't leakage ... plus one
very suspicious piece of code causing complaints.  I spent on the order of
hours sleuthing this one remaining problem, getting down to the level of
examining generated code, trying to figure out what Purify was complaining
about.  I finally resolved it to some sort of misunderstanding on Purify's
part--the code generated simply wasn't quite what it expected, so it mis-
diagnosed a problem.  Again, this is a soft spot for Purify; it's tied to
the compiler's code-generation...and the compiler writers aren't obligated
to notify the Purify folks when they change code output.

This left me with ... nothing at all!, and a fair bit of effort required
to get to that nothing.  Based on that, I can't see what Purify offers
to me.  For the problems it didn't find, I have to play user and say "I
don't know why it didn't find them.  I'm not going to examine what it's
doing internally; I just know it didn't help me."  For the false reports
from structure holes, I say "I don't care if this is inevitable; it makes
the reports useless.  I don't have time to filter through all this."
For the one real false-positive failure, I have to say "This makes me
suspicious of the technique--it's too delicately tied to the compiler's
output."
--
Dick Dunn    [e-mail]   -or-   raven!rcd    Boulder, Colorado
    ...Simpler is better.