Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!decwrl!ads.com!potomac!adiseker
From: adiseker@potomac.ads.com (Andrew Diseker)
Newsgroups: comp.sys.mac.programmer
Subject: malloc() problems ( was: Re: TC 4.0 and linked list ...)
Summary: you may still have problems later
Keywords: malloc free NewPtr DisposPtr
Message-ID: <8995@potomac.ads.com>
Date: 28 Jul 90 03:26:34 GMT
References: <1039@kluge.fiu.edu>
Reply-To: adiseker@potomac.ads.com (Andrew Diseker)
Followup-To: comp.sys.mac.programmer
Distribution: na
Organization: Advanced Decision Systems -- Arlington, Va
Lines: 39


	Anyone using the new (4.0 and later) malloc() and free() should be
aware of a potential loss of memory.  Apparently, for the change from 3.0 to 
4.0, the Symantec folks changed the implementation of the ANSI memory routines.
Malloc() and calloc() now only call NewPtr if the memory needed is larger than
15000 bytes.  If the memory needed is smaller, the library will try to find
some 'free' space in an internal linked list of 15000 byte blocks.  This is a
good idea in some respects, since NewPtr calls for 12 bytes, say, is very
expensive, and if the linked list doesn't have the unused space available, it
just has to NewPtr(15000) every so often.  
	The problem we ran into WRT the new method is this: the free() 
function _does not_ mark unused blocks, and the linked list is not compacted 
unless you call realloc() on the pointer!  Not only that, even if space were 
'free'd correctly, any 15000 byte blocks that had no 'allocated' pointers in
them are never DisposPtr'd!  The bottom line is that if you try to do what we 
did in our project, that is, malloc() and free() thousands of 12-64 byte 
objects over and over, you eventually run out of memory.  
	I mailed Rich Seigel telling him what we had found, and he replied 
that, yes, that is the way Symantec intended for the package to work, and if 
we wanted something better, we would have to write it ourselves.  This seemed 
fair enough, since Symantec was kind enough to supply their libraries' source 
code.  However, he never mentioned the bug with free().  Maybe someone who
knows 680x0 assembler could set me straight on that.  
	Anyway, we went back and modified the 3.0 version, fixing a realloc()
bug we found ( is ANSI non-compliance truly a bug? ), and redesigned part of
our code to reduce the number of malloc calls ( can you say hard-coded arrays?
Sure you can! ).  If anyone is interested, I may be able to let them have a 
copy of our allocation routines.

----
Andrew Diseker                            ( )-( )   Mouse-Tested!
Advanced Decision Systems                  /o o\    Hacker-Approved!
UUCP: sun!sundc!potomac!adiseker          / =v= \ ,--_
Internet:  adiseker@potomac.ads.com       ;;---;;     `--'
-- 
Andrew Diseker                            ( )-( )   Mouse-Tested!
Advanced Decision Systems                  /o o\    Hacker-Approved!
UUCP: sun!sundc!potomac!adiseker          / =v= \ ,--_
Internet:  adiseker@potomac.ads.com       ;;---;;     `--'