Re: Suggestions for C malloc debugging tool

jlilley@empathy.com (John Lilley)
9 Jan 1997 22:24:49 -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)
[2 later articles]
| List of all articles for this month |

From: jlilley@empathy.com (John Lilley)
Newsgroups: comp.compilers
Date: 9 Jan 1997 22:24:49 -0500
Organization: Nerds for Hire, Inc.
References: 97-01-050
Keywords: C, debug

Joerg Schoen wrote:
> I would like to get some comments about the following idea[...]
> a debugging tool as follows: A "preprocessor" that
> processes C to C and inserts a validity check prior to every memory
> access in the code. Obtaining the valid range of pointer variables is
> done in two steps.


Let me start off by saying that I believe *anything* to decrease the
chance of pointer errors in "C" is a good thing (assuming you must use
C at all). When programming 16-bit Windows 3.x, a useful trick was to
allocate a separate segment for each malloc(), which turned on the
built-in hardware segment boundary checking. It was great (as long as
you didn't need more than 2000 malloc's). It sounds like you want to
implement a sort of segmentation in software, which really promising.
Can you take over the global malloc()? Since you can't really change
a pointer into a (pointer,range) pair without breaking sizeof() and
all the object libraries, I assume that you are keeping a separate
table around that maps pointers to ranges? And then when the pointer
is accessed you check the table for the pointer value and compare it
to the allowed range...


Performance could be awful... other than that I can't think of
anything terribly wrong with the appraoch -- other than it's hard :)


john
[It's been done. See subsequent messages -John]


--


Post a followup to this message

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