From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Error: Could not reserve dynamic heap area. Date: Sat, 08 Nov 2014 10:10:52 +0200 Message-ID: <83sihuqfhv.fsf@gnu.org> References: NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1415434299 1945 80.91.229.3 (8 Nov 2014 08:11:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Nov 2014 08:11:39 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Nov 08 09:11:32 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xn17L-000796-MK for geh-help-gnu-emacs@m.gmane.org; Sat, 08 Nov 2014 09:11:31 +0100 Original-Received: from localhost ([::1]:35192 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xn17L-0006yZ-8C for geh-help-gnu-emacs@m.gmane.org; Sat, 08 Nov 2014 03:11:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xn175-0006xd-Ns for help-gnu-emacs@gnu.org; Sat, 08 Nov 2014 03:11:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xn16z-0004or-Pg for help-gnu-emacs@gnu.org; Sat, 08 Nov 2014 03:11:15 -0500 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:57694) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xn16z-0004ok-CE for help-gnu-emacs@gnu.org; Sat, 08 Nov 2014 03:11:09 -0500 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NEP00000NLFMF00@mtaout27.012.net.il> for help-gnu-emacs@gnu.org; Sat, 08 Nov 2014 10:06:19 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEP001IWNUJ0T00@mtaout27.012.net.il> for help-gnu-emacs@gnu.org; Sat, 08 Nov 2014 10:06:19 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:100846 Archived-At: > Date: Sat, 8 Nov 2014 03:39:20 +0100 > From: Alexander Shukaev > > 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 > > Date: Tuesday, May 27, 2014 19:31:17 > > Committer: Eli Zaretskii > > > > > 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.