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

[Ken Brown]

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