Re: Error: Could not reserve dynamic heap area.

[Eli Zaretskii]

> Date: Sat, 8 Nov 2014 03:39:20 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> 
> I have to admit that I've been facing many difficulties building the
> `emacs-24' branch for Windows lately. All of them come primarily from the
> fact that lots of yummy changes in the `trunk' are absent in the `emacs-24'
> branch. I could bypass some problems, but here is something that is too
> much to work around.

Why are you posting build problems for development versions here?
It's not the right place to discuss them.

> Due to the following commit in the `trunk':
> 
> Commit: c909d23bfbf5dbaa5ddddc586eb8f3983bea6ace [c909d23]
> > Parents: 5ca3aee65a
> > Author: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Tuesday, May 27, 2014 19:31:17
> > Committer: Eli Zaretskii <eliz@gnu.org>
> >
> 
> 
> Use mmap(2) emulation for buffer text on MS-Windows.
> 
> 
> when I build `trunk' everything finishes smoothly. On the other hand, when
> I build `emacs-24' these changes are not present and, as a result, Emacs is
> being configued with
> 
> Should Emacs use the GNU version of malloc?    yes
> > Should Emacs use a relocating allocator for buffers?  yes
> > Should Emacs use mmap(2) for buffer allocation?    no

This is as intended.  However, the trunk commit you mention is not a
bug fix, it is a fundamental change in how Emacs on Windows allocates
memory.  Also, the way Emacs allocates memory on the emacs-24 branch
have worked for many years and many Emacs versions.  So it ought to
work for you as well; there's probably some minor glitch that prevents
that.

> Now the problem is that with this configuration the x64 version is built
> just fine, but the x86 version build fails with
> 
> Error: Could not reserve dynamic heap area.
> > Error: Could not reserve dynamic heap area.
> > Error: Could not reserve dynamic heap area.

This means Emacs could not reserve the address space for its heap when
it starts up.  The error message comes from w32heap.c:allocate_heap.
Please step with a debugger through that function and see what goes
wrong there.

One possibility is that you are using MinGW64 to build the 32-bit
binary, and the preprocessor conditional in that function is not set
correctly, so the 32-bit binary tries to reserve 256GB of memory,
which will always fail for 32-bit binaries.  There's confusion
regarding which preprocessor symbol indicates a 64-bit build by
MinGW64; if this is the problem, try _W64 instead of _WIN64.

> Now I get it that the developers don't merge `trunk' into `emacs-24'. Does
> that mean that we will see all those good changes from `trunk' only in
> `emacs-25'? What a pity if that's the case.

The emacs-24 branch is in bugfix-only state.  New features, such as
the changes in memory allocations mentioned above, will not appear on
that branch.  But bugs in that branch will be fixed.  However, memory
allocation used by emacs-24 is solid and doesn't need the trunk fixes
in order to work.  The reason for these failures must be something
relatively simple.

Those who want the new features available on the trunk can always
build the trunk version and use it.