Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!sgi!yohn@tumult.asd.sgi.com
From: yohn@tumult.asd.sgi.com (Mike Thompson)
Newsgroups: comp.sys.sgi
Subject: Re: Bus error DURING call to malloc()
Summary: Consider that the problem might be in your code.
Keywords: help bus error malloc
Message-ID: <62083@sgi.sgi.com>
Date: 11 Jun 90 21:58:55 GMT
References: <14525@thorin.cs.unc.edu>
Sender: yohn@tumult.asd.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 44

In article <14525@thorin.cs.unc.edu>, taylorr@glycine.cs.unc.edu (Russell Taylor) writes:
> 
> 	We are running OS 3.2.2 on an IRIS 4D/240GTX.  I ran a program and
> got the proverbial 'Bus error (core dumped)' message.  The catch is that
> when I run dbx and look for the error, it tells me that the error occured
> IN malloc():
> 
> ...Source (of malloc.c) not available...
> 
> 	There are several calls to malloc() in the code.  There have been
> successful calls before this call is made.  All calls are passed constant
> references, and this code compiles and runs correctly on a variety of other
> machines (VAX, sun 4, DecStation).
> 
> 	Is there a known bug (and hopefully fix) for this?
> 
> 	Thanks,
> 	Russell Taylor
> 	taylorr@cs.unc.edu

I cannot guarantee that there are no bugs in malloc (I assume you are
getting malloc from libc), but I don't know of any (besides performance
problems when allocating many memory areas).  But I have seen many,
many user programs that bomb in malloc because the user code overran
the memory allocated by a call to malloc.  malloc(strlen(s)) and
copying s is a classic way to get into trouble (user forgets that
strlen does not account for the trailing null character) -- there are
many other possibilities.

Since malloc(3X) -- the malloc in /usr/lib/libmalloc.a -- aligns
requests to eight-byte boundaries and malloc(3C) aligns only to
four-bytes, switching to libmalloc may help if only that it masks gives
the caller a little more unrequested rounding space.

This may be what's happening with the malloc calls on your Vaxen, etc.

Now if your program does make many calls to malloc, it is usually best
to link with libmalloc.  The two mallocs do have slightly different
behavior -- libmalloc will return a null pointer when asked for zero
bytes and will ignore a null pointer on free; libc malloc will not
touch the just-freed space until (at least) the next call to malloc/free.
Usually these behaviors are not a concern.

Mike Thompson