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

[Eli Zaretskii]

> Date: Tue, 09 Aug 2011 16:09:48 -0400
> From: Ken Brown <kbrown@cornell.edu>
> 
> The code in src/gmalloc.c makes assumptions about how a system maintains 
> its memory that are not necessarily valid.  In particular, they will not 
> be valid on Cygwin starting with version 1.7.10 (which will almost 
> certainly be released before emacs 24.1).  The problem is that malloc 
> initialization is done by temacs, and the results are dumped into emacs. 
>   This includes the setting __malloc_initialized = 1, so no malloc 
> initialization is done when emacs is run.  But the dumped value of 
> _heapbase, while appropriate for temacs, may not point to the beginning 
> of the runtime heap for emacs.  This causes all code that uses the BLOCK 
> and ADDRESS macros to be invalid.

If Cygwin developers cannot or won't add to the Cygwin memory
allocation enough features and knobs to cater to the special needs of
Emacs dumping, then your only hope is to make Cygwin-specific changes
to Emacs.

You will see that 2 other ports that need to live with Windows memory
allocation either have such knobs and features (DJGPP, used to build
the DOS port; see the beginning of src/msdos.c) or use their own
emulation of sbrk that upholds the contract expected by gmalloc.c and
ralloc.c (w32heap.c, for the native Windows build).

> 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.

> 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.

> 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?)

> I made one naive attempt to do this, but it didn't work (and it was
> Cygwin specific).  Namely, I made unexec (for Cygwin) set
> _malloc_initialized = 0 before dumping.  The resulting emacs aborted
> as soon as it was started.  I haven't figured out what went wrong,
> but I'm not sure that's the right answer anyway.

One more evidence that something else is at work here.  I would
suggest to walk through the session that reinitializes the heap after
unexec and see what goes wrong there.