Re: Suggestions for C malloc debugging tool

T.E.Dickey <dickey@clark.net>
12 Jan 1997 11:28:16 -0500

          From comp.compilers

Related articles
Suggestions for C malloc debugging tool f81@ix.urz.uni-heidelberg.de (1997-01-07)
Re: Suggestions for C malloc debugging tool vlaures@igcom.fr (Laurent Sabarthez) (1997-01-09)
Re: Suggestions for C malloc debugging tool jlilley@empathy.com (1997-01-09)
Re: Suggestions for C malloc debugging tool colas@aye.inria.fr (1997-01-09)
Re: Suggestions for C malloc debugging tool lijnzaad@ebi.ac.uk (Philip Lijnzaad) (1997-01-12)
Re: Suggestions for C malloc debugging tool dickey@clark.net (T.E.Dickey) (1997-01-12)
Re: Suggestions for C malloc debugging tool stephens@math.ruu.nl (1997-01-12)
Re: Suggestions for C malloc debugging tool cef@geodesic.com (Charles Fiterman) (1997-01-12)
Re: Suggestions for C malloc debugging tool patil@ch.hp.com (Harish Patil) (1997-01-22)
Re: Suggestions for C malloc debugging tool taustin@ichips.intel.com (1997-01-25)
Re: Suggestions for C malloc debugging tool mercier@cinenet.net (1997-01-25)
| List of all articles for this month |

From: T.E.Dickey <dickey@clark.net>
Newsgroups: comp.compilers
Date: 12 Jan 1997 11:28:16 -0500
Organization: Clark Internet Services, Inc., Ellicott City, MD USA
References: 97-01-050
Keywords: storage, C, debug

Joerg Schoen <f81@ix.urz.uni-heidelberg.de> wrote:
: I would like to get some comments about the following idea: A lot of
: trouble in developing C code results from bad memory accesses through
: invalid or uninitialized pointers, through subscripts out of range and
: so on. Unfortunately these errors usually show up much later and are
: hard to track down.


been done. several times, e.g., (for free, as opposed to a commercial
product):


http://www-ala.doc.ic.ac.uk/~phjk/BoundsChecking.html
>Bounds Checking for C


: [This sounds awfully familiar, I'm sure it's been done many times before.
: It's a good idea, would be interesting to hear experience re how well it
: works in practice. -John]


Purify does it by instrumenting the object code, therefore cannot pick
up some types of indexing errors. But it's fast, and useful with a
variety of languages.


Insight++ does it by instrumenting the source code, can pick up
indexing errors based on source semantics. But it's abysmally slow
(2-3 orders of magnitude slower than Purify), and tied to the dialect
of C for which it's written. I'd say it's only useful for embedded
applications, or for toy programs (<10kloc).


The free version cited is more like the latter (uses source semantics,
with a modified version of gcc). There's also a Purify-clone called
'checker' that runs on Linux (I've used all but this one - the
reported robustness is too low to get me interested).


--
Thomas E. Dickey
dickey@clark.net
http://www.clark.net/pub/dickey
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.