Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.sysv386
Subject: Re: malloc() problems
Keywords: malloc, ISC, Esix
Message-ID: <1991Apr08.140442.13343@virtech.uucp>
Date: 8 Apr 91 14:04:42 GMT
References: <1991Apr05.211827.23819@dialogic.com> <1991Apr7.221646.22223@nusdecs.uucp>
Organization: Virtual Technologies Inc.
Lines: 19

rwhite@nusdecs.uucp (Robert White) writes:
>In short, before you go trying to reverse-engineer your malloc(3) library
>you should review the pointer usages in all your source and home-grown
>libraries.  Functions most likley to blame are things like strcat, getstr, 

If you read his message again, you will see that he knew that it was probably
a problem in his code, but the standard malloc did not have enough debugging
capabilities to track this down.

>and the like.  Anyplace you pass a pointer to an aray that will be written on
>without the size of the aray you should be suspicious.

Yes and it may take you a long time to track down (especially if it 
is not all your own code).  That is why I put together the debugging version
of the library.  It makes tracking down malloc problems much much easier.
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170