Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!milton!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!ucsd!usc!apple!mips!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: Bus error DURING call to malloc()
Keywords: help bus error malloc
Message-ID: <62158@sgi.sgi.com>
Date: 12 Jun 90 23:34:40 GMT
References: <14525@thorin.cs.unc.edu> <1990Jun10.211156.16153@calgary.uucp> <10822@medusa.cs.purdue.edu>
Sender: vjs@rhyolite.wpd.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 36

In article <10822@medusa.cs.purdue.edu>, krk@cs.purdue.EDU (Kevin Kuehl) writes:
> In article <789@ki.UUCP> dwatts@ki.UUCP (Dan Watts) writes:
>
> Another thing you can do (if you are fortunate enough to have access
> to a Sun4) is to use the `malloc_debug(2)' on a Sun4.  This is one of
> the greatest tools I have ever used.   On every call to malloc, it
> checks the heap and verifies that it is not corrupted [...]
> 
> This would be great to have under Irix, don't you think?  Whatd'ya say
> at SGI?  I would really appreciate this feature.


We've shipped versions of malloc that did this in the distant past.  I
don't think the malloc(3) shipped on 4D's in the last 2-3 years had this.
Howver, consider the mallopt() function and the following paragraph, cut
from a window displaying the IRIX 3.3 malloc(3X) man page:

|    M_DEBUG  Turns debug checking on if value is not equal to 0, otherwise
|             turns debug checking off.  When debugging is on, each call to
|             malloc and free causes the entire malloc arena to be scanned and
|             checked for consistency.  This option may be invoked at any
|             time.  Note that when debug checking is on, the performance of
|             malloc is reduced considerably.

There have been internal discussions about possibly enhancing this feature
in a future release to make it slower and more paranoid.  (This would be good.)

If you complain enough, you might convince the powers that be to ship some
neat "memory-leak" tools developed in the window system wars.

It is worth noting that the semantics of libmalloc and ancient malloc
differ slightly.  Particularly sloppy code has trouble with libmalloc.


Vernon Schryver
vjs@sgi.com