GNU bug report logs - #9273
23.3; malloc initialization should (sometimes) happen at runtime

Previous Next

Full log

Message #59 received at 9273 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "9273 <at> debbugs.gnu.org" <9273 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#9273: 23.3; malloc initialization should (sometimes) happen
	at runtime
Date: Sat, 13 Aug 2011 11:33:59 -0400

On 8/13/2011 11:07 AM, Stefan Monnier wrote:
>>>> _heapinfo is indeed consistent with the current heap.  But the pointer
>>>> that was passed to realloc points into the old heap.  So applying BLOCK
>>>> to that pointer yields an absurd result.  I can easily catch such cases
>>>> by testing for ptr<   _heapbase, as in my patch to _free_internal_nolock,
>>>> but I have to figure out the best way to handle them once I've caught
>>>> them.
>>> malloc a buffer, then copy the contents of the old one to the new
>>> one.  You will have to know the size of the old block, which means you
>>> will have to access the old copy of _heapinfo.
>> Thanks!  That's much easier than what I was trying to do.
>
> Wouldn't it be easier to try and convince malloc to keep using the old
> _heapinfo?

Probably.  That would keep me from having to get involved in the details 
of how _heapinfo works, and it would probably be less error prone.  So I 
would do something like the following:

1. Temporarily restore the pre-dump malloc state.
2. Call xrealloc, getting storage of the new size in the old heap.
3. Copy the contents into a temporary buffer, and then free the recently 
allocated storage in the old heap.
4. Restore the malloc state, call malloc, and then copy the contents of 
the temporary buffer into the just-acquired storage in the new heap.

Is that what you had in mind?

Ken

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.