[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9273: 23.3; malloc initialization should (sometimes) happen at runti

From: Ken Brown
Subject: bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime
Date: Sat, 13 Aug 2011 11:33:59 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0

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
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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]