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

[Ken Brown <kbrown@cornell.edu>]

On 8/13/2011 4:05 AM, Eli Zaretskii wrote:
>> Date: Fri, 12 Aug 2011 16:24:20 -0400
>> From: Ken Brown<kbrown@cornell.edu>
>> CC: "9273@debbugs.gnu.org"<9273@debbugs.gnu.org>
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x006368f5 in _realloc_internal_nolock (ptr=0x897040, size=28)
>>      at gmalloc.c:1394
>> 1394      type = _heapinfo[block].busy.type;
>> (gdb) p block
>> $1 = 4294838425
>
> I'm confused: since you patched unexecw.c to set __malloc_initialized
> to zero, the dumped Emacs should have called malloc_initialize_1,
> which should have allocated a new copy of _heapinfo, that was supposed
> to be consistent with the current heap.  Why isn't that working? why
> `block' still gets a value that is relative to the "old" _heapinfo?

_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.  I have work in progress that tries to keep track of both heaps, 
but I haven't got it working yet.

An alternative would be to have realloc return NULL (or some other 
special value) in these cases, but then I would have to find all 
possible callers of realloc (with pointers to the old heap) and make 
sure they know how to deal with that return value.  I'm guessing my 
first approach is safer and easier to implement.

Ken