Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!lll-lcc!lll-crg!topaz!oarv rd!cmcl2!phri!delftcc!sam
From: sam@delftcc.UUCP (Sam Kendall)
Newsgroups: net.lang.c
Subject: Re: oops, corrupted memory again!
Message-ID: <142@delftcc.UUCP>
Date: Tue, 29-Apr-86 11:06:17 EDT
Article-I.D.: delftcc.142
Posted: Tue Apr 29 11:06:17 1986
Date-Received: Fri, 2-May-86 23:48:22 EDT
References: <4495@cbrma.UUCP>
Organization: Delft Consulting Corp., New York
Lines: 27
Keywords: malloc free stack tools core
Summary: There is such a tool: Bcc

In article <4495@cbrma.UUCP>, trl@cbrma.UUCP writes:
> 	Are there any "malloc" routines that check for modification of
> malloc's link pointers by the "user's" code?   Close to 70% of by bugs
> are stack/memory problems were I use more space than I allocated.  Tracking
> this kind of problem is horrible.
> ....
> 	This problem is not unique to my code, I know others that are
> plagued by these bugs also.  A programmer only needs one of these bugs
> in a large piece of software to waste a week of effort.
> ....
> 	I am interested in any tools, recommend tions, or routines that may
> help.  Thanks.

The Bcc Compiler, a tool made by Delft Consulting Corp., catches bugs of
this sort (as one case of "pointer out of bounds") and tells you exactly
where in your source the transgression occurred.  An item about Bcc was
recently posted to mod.newprod.  Please contact me for more info.

Also, if you have source, you can recompile malloc to check its internal
pointers stringently.  At least you could on V7, and I doubt anyone has
removed this capability.  This won't locate your bug, but it might help.

----
Sam Kendall			{ ihnp4 | seismo!cmcl2 }!delftcc!sam
Delft Consulting Corp.		ARPA:  delftcc!sam@NYU.ARPA
432 Park Avenue South		Phone: +1 212 243-8700
New York, NY  10016