Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.i386
Subject: Re: Memory Fault, core Dumped (ISC 2.0.1)
Keywords: memory fault core dumped malloc()
Message-ID: <1990Feb24.021235.8271@virtech.uucp>
Date: 24 Feb 90 02:12:35 GMT
References: <469@telxon.UUCP>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 27

In article <469@telxon.UUCP> gorpong@telxon.UUCP (Gordon C. Galligher) writes:
>A while back (I don't know how long) I posted an RFH (Request For HEEEELP)
>on this newsgroup about malloc() causing a memory fault and core dump on
>Interactive Systems Corporation's 386/ix 2.0.1 and I received a couple of
>responses which solved the problem.  The symptom, to repeat myself, occurs
>on large (over 12K) programs requesting memory via the malloc() call.  It was
>entirely inconsistent and it happened as root and whomever else.  If you
>link the code with the -lmalloc option the problem goes away!  This causes
>the linkage of the /lib/libmalloc.a file rather than the standard malloc()
>call in the libc.a file.

I would be very leery about using the program.  I don't think you actually
solved the problem, just hid it.  You should use the standard malloc
functions and track down the problem that is probably in your code.  I 
say that the problem is probably in your code because there are hundreds
of programs on the system that use the libc.a malloc without any 
problems.

The correct way to fix this problem is to track down the cause of the 
memory fault in your code.  A 12K program is not a very large program
and should be somewhat easy to debug.

-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+