Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ki!dwatts
From: dwatts@ki.UUCP (Dan Watts)
Newsgroups: comp.sys.sgi
Subject: Re: Bus error DURING call to malloc()
Keywords: help bus error malloc
Message-ID: <789@ki.UUCP>
Date: 12 Jun 90 13:21:50 GMT
References: <14525@thorin.cs.unc.edu> <1990Jun10.211156.16153@calgary.uucp>
Organization: Ki Research, Inc.  Derry, NH
Lines: 27

In article <1990Jun10.211156.16153@calgary.uucp> paquette@cpsc.ucalgary.ca (Trevor Paquette) writes:
>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():
> < stuff deleted >
>   Note: this does not 'fix' the problem.. you are now using a different
>     malloc.

My experience has been that this error is caused by a program writing
outside the bounds of a malloc'd area.  This causes the hidden memory
management headers to get corrupted.  A quick hack would be to add some
constant pad to all malloc's.  Try adding 128 bytes and see if that does
it. Since my mistakes are usually in writing one byte too much, a pad
of 16 works ok.  Note that this hasn't solved the code problem, it's just
defensive programming.  You might also not failures in printf() due to
the same reason.  I usually track this down by putting in calls to malloc()
in other places in the code and try to find the _bad_ code by seeing which
ones work, and which ones die (note to free() the malloc()'d mem just
after getting it).
-- 
#####################################################################
# CompuServe: >INTERNET:uunet.UU.NET!ki!dwatts    Dan Watts         #
# UUCP      : ...!uunet!ki!dwatts                 Ki Research, Inc. #
############### New Dimensions In Network Connectivity ##############