Date:	Mon, 30 Jan 95 22:32:07 EST
From:	peprbv AT cfa0 DOT harvard DOT edu (Bob Babcock)
To:	enrico AT max DOT tiac DOT net
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: malloc bug?
Reply-To:	babcock AT cfa DOT harvard DOT edu

> 	I don't see how this could be a "that's my fault" crash, but I've 
> enough faith in DJGPP to think that there is some way I am missing.  Can 
> anyone tell me what I may be doing wrong to get this sort of crash?  If 
> not, is something wrong with DJGPP's malloc()?

Malloc typically allocates a little more space than you asked for and stores
housekeeping information in that extra memory (at an address just below what
it returns to you).  If you index backwards or off the end of your allocated
space, you may clobber this housekeeping information.  That probably won't
have any immediate effect, but when you free that memory, the bad info may
cause a crash, or it may corrupt the list of free memory and cause problems
latter.  Such bugs can be a b@#$h to find because the crash occurs long after
the cause.  One debugging aid is a modified malloc/free which stores
additional information so it can do consistency checks.  I know I've seen
such libraries, but off hand, I can't give a pointer to one.  It's not to
hard to roll your own:
   #define malloc(x) my_malloc(x)
   #define free(x) my_free(x)
my_malloc allocates a few extra bytes at the beginning and end of the block
and inserts a magic value.  my_free checks to make sure that the magic number
is still there, then inserts some other value to indicate that the block has
been freed.

- Raw text -