Date:	Tue, 11 Aug 1998 10:04:17 +0200 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
To:	Robert Hoehne <robert DOT hoehne AT gmx DOT net>
cc:	djgpp-workers <djgpp-workers AT delorie DOT com>
Subject:	Re: Bugs in malloc.c
In-Reply-To:	<35CF8F77.A9BFBE94@gmx.net>
Message-ID:	<Pine.A32.3.91.980811094642.319770A-100000@ieva05.lanet.lv>
MIME-Version:	1.0

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

- Raw text -