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

[Ken Brown <kbrown@cornell.edu>]

On 8/10/2011 11:56 AM, Eli Zaretskii wrote:
>> Date: Tue, 09 Aug 2011 16:09:48 -0400
>> From: Ken Brown<kbrown@cornell.edu>
>
>> But when the dumped emacs is run, it uses Cygwin's sbrk, which
>> allocates memory on a heap that won't (as of Cygwin 1.7.10) be
>> contiguous with the static heap.  The saved value of _heapbase,
>> which points into the static heap, is never changed, but it will
>> mess up later calculations as soon as sbrk is called for the first
>> time.
>
> Are you sure this is all that's at work here?  AFAIR, gmalloc does
> have code to cope with non-contiguous memory regions returned by sbrk.

The issue isn't that sbrk returns non-contiguous regions.  The issue is 
that two different of sbrk are used.  One is used when temacs is 
running, and a different one is used when the dumped emacs.exe is 
running.  This is controlled by the Cygwin-specific code in gmalloc.c, 
and it has to do with the way unexec works in the Cygwin build of emacs.

>> All of this is described in detail on the Cygwin mailing list in the
>> thread starting at
>>
>>     http://cygwin.com/ml/cygwin/2011-08/msg00153.html
>>
>> See especially
>>
>>     http://cygwin.com/ml/cygwin/2011-08/msg00193.html
>
> I have read all the discussion there, but I'm sorry to say that I
> cannot figure out what you are talking about: there's too much
> Cygwin-isms in that thread that I couldn't penetrate.

Thanks for trying.

>> Maybe the solution is for emacs to do malloc initialization, including
>> the assignment of _heapbase, every time it starts, at least on systems
>> that use gmalloc.c.
>
> Most supported systems don't need that.  The native Windows build
> indeed does, see w32heap.c.  Perhaps you could reuse some or even most
> of it for Cygwin.  (What is so special about the Cygwin sbrk that is
> worth sticking to it?)

Thanks for the suggestions.

Ken