From: Christopher Croughton 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk 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