Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ames!amdahl!uunet!ingr!dan
From: dan@ingr.com (Dan Webb)
Newsgroups: comp.sys.sgi
Subject: Re: -lmalloc
Message-ID: <3724@ingr.com>
Date: 31 Jan 89 02:36:23 GMT
References: <4143@pt.cs.cmu.edu>
Organization: Intergraph Corp. Huntsville, Al
Lines: 24

in article <4143@pt.cs.cmu.edu>, scotts@isl1.ri.cmu.edu (Scott Safier) says:
> We have several personal Iris's running IRIX 3.1.  We have ported some
> software from BSD systems, and found that there is a difference
> between the C function malloc in /usr/lib/libbsd.a and
> /usr/lib/libmalloc.a.  In particular the malloc in the latter library
> is 8 times faster (by our estimates) than the malloc in the bsd
> library (or the malloc provided with gnu emacs).
> 
> But there is also something strange with -lmalloc.  Sometimes,
> programs which execute perfectly with the bsd malloc, core dump when
> the other malloc is invoked.  For example, using X lib with bsd malloc
> is ok, but with lmalloc core dumps occur.

I've had the same problem with -lmalloc (also known as malloc(3X)).
The crashes are probably caused by the fact that this implementation of
malloc, for some reason, treats a request for zero bytes as invalid.
It therefore returns a NULL pointer, which is probably passed to free()
or realloc() later, resulting in a core dump.

I probably don't have to convince too many people of this, but a request
for zero bytes is by no means an invalid request.  I think -lmalloc should
be fixed.

	 - Dan Webb