Newsgroups: comp.sys.next
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixa.cc.columbia.edu!das15
From: das15@cunixa.cc.columbia.edu (Douglas A Scott)
Subject: Re: Help with malloc()
Message-ID: <1991Mar21.032859.6145@cunixf.cc.columbia.edu>
Sender: usenet@cunixf.cc.columbia.edu (The Network News)
Nntp-Posting-Host: cunixa.cc.columbia.edu
Reply-To: das15@cunixa.cc.columbia.edu (Douglas A Scott)
Organization: Columbia University
References: <1991Mar21.010307.18749@neon.Stanford.EDU>
Distribution: usa
Date: Thu, 21 Mar 91 03:28:59 GMT

In article <1991Mar21.010307.18749@neon.Stanford.EDU> zimmer@calvin.stanford.edu (Andrew Zimmerman) writes:
>
>    I have a program that runs just fine on a DEC3100 and a Sparc 1, but
>doesn't run correctly on my NeXT.  It acts line the static buffer used
>by strtok is being written over by another part of my code.  This leads
>to two possibilities, one is that my code is broken on all of the machines,
>but I haven't gotten bitten yet on the other platforms, or there is a bug
>in the malloc on the NeXT.  I had read that there was some problem with
>alloc and malloc on the NeXT (in an article on comp.sys.next).  Is there
>any truth to a possible bug in malloc?  

	I have had the same problems with a large program that compiles
	and runs on Suns, DECs and SPARCs without an error, but gives me
	no end of grief under 2.0 on the cube.  It ran great under 1.0a,
	though.  I have tried all the tricks: mallocing a minimum of 16,
	32, 64, etc bytes, etc.  The only way I could get it to work was
	to turn off all malloc_debugging altogether (I had been using
	malloc_debug(8) in the code).

	Compiling with -lMallocDebug and running the MallocDebug App allows
	you to examine the running code in detail for memory errors.  Maybe
	2.0 is just better at catching these things...

___________________________________________________________________________
Douglas Scott
zardoz!doug%woof.columbia.edu