From:	Christopher Croughton <crough45 AT amc DOT de>
Message-Id:	<97Nov27.183707gmt+0100.17029@internet01.amc.de>
Subject:	Re: malloc() bug?
To:	gaggi AT dulcamara DOT cs DOT unibo DOT it, djgpp AT delorie DOT com
Date:	Thu, 27 Nov 1997 17:35:47 +0100
Mime-Version:	1.0

gaggi AT dulcamara DOT cs DOT unibo DOT it (Nicola Gaggi)  wrote:

> I am wondering if anyone out there has had the same problem:
> I am writing a program that need to dinamically allocate a huge number of
> little buffers (about 10 bytes each), but I have run into problem with
> malloc(), i receive SIGSEGV inside the malloc() code. 
> The program code seems correct, and anyway it is not particularly
> complicate, it only performs some allocation and copy, so what it can be?
> Every malloc'ed pointer is free'ed up correctly. 
> Is it a bug of malloc() function? Any suggestion? 

SIGSEGV inside malloc is almost certainly an indication of the free
chain being corrupted.  Common reasons for this include:

  Overwriting the end or beginning of malloced memory
  Doing free() on the same buffer more than once
  Doing free() on memory not obtained by malloc

This is probably not an exhaustive list, it's just the ones I've done most :-(
I've never seen DJGPP's malloc do a SIGSEGV on anything which wasn't a
problem with the calling program, but note that the actual error can occur
a long time after the actual fault.

Before you say "but I'm not doing any of those", /prove it/.  I've seen too
many times where a bug has 'obviously' not been in the source code and
then proved wrong to believe it (many of them have been my bugs!).  If
you still can't find it, post the code (if as you say it's not very 
complicated then it shouldn't be too big).  Try taking out the copies.
Try tracing each malloc() and free().

Note also that DJGPP's malloc (in fact most versions of malloc) is not very
efficient with small chunks of memory.  This is because it (a) has to add 
another word (32-bits) to the start of each block for the length, and (b)
has to align the memory to a 4-byte boundary.  This can mean wasting up to
7 bytes per block, which if it's only 10 bytes long is a 70% overhead.

(Actually, it might align it to the worst case, 16 byte boundaries.  I know
some versions do, I don't remember if DJGPP's is one of them.)

Chris C

- Raw text -