Date: Tue, 11 Aug 1998 10:04:17 +0200 (WET) From: Andris Pavenis To: Robert Hoehne cc: djgpp-workers Subject: Re: Bugs in malloc.c In-Reply-To: <35CF8F77.A9BFBE94@gmx.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 11 Aug 1998, Robert Hoehne wrote: > Hi all others, > > there are probably still some bugs in malloc.c. > Currently I have really not the time to search > for them. So I only want to inform you, that I > had some crashes with my program (I localized > them finally to free()) but I coudn't see a problem > in my code. So I simply tried an other malloc > (now I'm warned because of the other bugs I found) > namely the file bsdmallo.c and the crash was gone. It is possible if other malloc() rounds up size of requested memory (similary as fmalloc.c or malloc() from djdev201). I suggest using fortify or similar package to track down memory overruns. My experience shows that crashes in free() often is caused by memory corruption from my program instead of malloc() or free(). And it's often not so easy to find some memory corruption related problem in large program. > > And the behaviour is reproducable by me but I > cannot send the code and also haven't the time > to produce a small test case. Maybe there is > someone else who can take e deeper look in the > malloc's and check it for bugs. I built egcs-2.91.53 (19980803) for DJGPP using djdev202 and only thing I had to patch in djdev202 were the bug in realloc() You mentioned some time ago. No other crashes yet. Bug in realloc() caused some crashes in cc1.exe while compiling some sources which disappeared when I applied the patch. > > Hope, anybody will find the bug since I think > that these functions should be as best as possible > bugfree or we should make the bsdmalloc the default > until the new ones are checked enough. > Andris