|
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 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
[Prev in Thread] | Current Thread | [Next in Thread] |