Path: utzoo!news-server.csri.toronto.edu!rutgers!ucsd!sdcc6!sdcc13!cpenrose
From: cpenrose@sdcc13.ucsd.edu (Christopher Penrose)
Newsgroups: comp.sys.next
Subject: Re: malloc() problems under 2.0
Summary: see, what did I tell you guys
Keywords: bugs, malloc, memory, hoax
Message-ID: <17176@sdcc6.ucsd.edu>
Date: 4 Mar 91 18:54:36 GMT
References: <1991Mar4.025906.24602@solo.csci.unt.edu>
Sender: news@sdcc6.ucsd.edu
Distribution: usa
Organization: University of California, San Diego
Lines: 23

In article <1991Mar4.025906.24602@solo.csci.unt.edu> doug@ponder.csci.unt.edu (Douglas A. Scott) writes:
>I just finished recompiling the source for a large piece of software to be
>sure that it would work properly under 2.0.  It is pure C code, no OOP stuff.
>When I try to run it I get:
>
>Smashed zone. Header size invalid
>Malloc corrupted entering malloc

You may get some mail from some people telling you that your own software
is hosed and that NeXT's malloc() is not a problem.  I have had problems
with malloc() myself.  In general, I have solved the problems by applying
a minimum allocation size (8192 bytes) for *every* malloc() space allocation.
People then accused me of having pointer indices that were out of bounds.
These people think they are so clever.  Even if I mailed them a copy of every
pointer reference with its index these people would not be convinced.  Gdb
has shown me on several occasions that pointer values are often corrupted 
by non-related code.  I have been recommended to use the new zone 
allocation classes; however, I have not had time to experiment with them yet.  
Research and application of these new (albeit NeXT specific) memory management 
classes may be worthwhile. 

Christopher Penrose
jesus!penrose