Subject: RE: Bug in gnumalloc
To: David Laight <david@l8s.co.uk>
From: Stuart Brooks <Stuartb@cat.co.za>
List: tech-userlevel
Date: 06/07/2002 15:07:50
It appears that when the new indices are created, they are allocated a
seperate block of memory at the end of the existing heap. So they don't try
to use any freed memory as far as I can see. It is only in the freeing up of
the old indices that the problems arise. I would have to check again to be
sure :)

 Stuart

-----Original Message-----
From: tech-userlevel-owner@netbsd.org
[mailto:tech-userlevel-owner@netbsd.org]On Behalf Of David Laight
Sent: Friday, June 07, 2002 2:37 PM
Cc: tech-userlevel@netbsd.org
Subject: Re: Bug in gnumalloc


>
> However (and herein lies the problem) the call to morecore might need to
add
> space for new indices, and this results in the old indices being freed via
a
> call to _free_internal() in free.c. This is not normally a problem, except
> in the case where the old indices lay directly before the last free block.
> If this is the case, then _free_internal frees the old indices and
combines
> it with last free block to produces a *new* free block whose starting
point
> is no longer _heapinfo[block] (line 5: above). This means that we think we
> are updating part of the free chain, whereas in actual fact we are
updating
> a now unused block.

I presume there is also the additional bug whereby the new indices are
allocated out of the free item that was at the end of the memory area?

	David

--
David Laight: david@l8s.co.uk