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

[Ken Brown <kbrown@cornell.edu>]

On 8/12/2011 7:33 AM, Eli Zaretskii wrote:
>> Date: Fri, 12 Aug 2011 06:10:35 -0400
>> From: Ken Brown<kbrown@cornell.edu>
>> CC: "9273@debbugs.gnu.org"<9273@debbugs.gnu.org>
>>
>> On 8/12/2011 2:54 AM, Eli Zaretskii wrote:
>>>> Date: Thu, 11 Aug 2011 17:45:41 -0400
>>>> From: Ken Brown<kbrown@cornell.edu>
>>>> CC: "9273@debbugs.gnu.org"<9273@debbugs.gnu.org>
>>>>
>>>> The problem was that realloc got called on memory that had been
>>>> allocated prior to dumping, and the malloc information that was used
>>>> then had disappeared.
>>>
>>> Can you show the code which called realloc on that memory?  I'm
>>> surprised that Emacs does that, but perhaps I'm missing something.
>>
>> Here's the code that I stumbled across (as a result of a SEGV).  I
>> haven't checked to see if there are other examples.  From terminal.c:
>>
>> /* Deletes the bootstrap terminal device.
>>      Called through delete_terminal_hook. */
>>
>> static void
>> delete_initial_terminal (struct terminal *terminal)
>> {
>>     if (terminal != initial_terminal)
>>       abort ();
>>
>>     delete_terminal (terminal);
>>     initial_terminal = NULL;
>> }
>
> delete_terminal doesn't call realloc, it just calls xfree.

Maybe I mis-remembered where the call to realloc is.  I'll reproduce it 
later and let you know.  (I don't have time at the moment.)  But I 
assure you that I did a backtrace showing that realloc was called on 
something related to terminals.

> Do the problems with the Cygwin build go away if the call to
> delete_terminal is commented out?

No.  At the very least, I have to force reinitialization of malloc. 
Otherwise the BLOCK macro yields wrong results that lead to infinite 
looping or crashing.  After reinitialization, I have to be able to 
handle calls to free() on memory allocated prior to dumping.  Probably 
it's OK to just ignore such calls.  If I can also take care of calls to 
realloc too, everything will be OK.

Ken