From unknown Fri Jun 20 07:14:16 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#18995 <18995@debbugs.gnu.org> To: bug#18995 <18995@debbugs.gnu.org> Subject: Status: Error: Could not reserve dynamic heap area. Reply-To: bug#18995 <18995@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:14:16 +0000 retitle 18995 Error: Could not reserve dynamic heap area. reassign 18995 emacs submitter 18995 Alexander Shukaev severity 18995 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 08 10:23:10 2014 Received: (at submit) by debbugs.gnu.org; 8 Nov 2014 15:23:10 +0000 Received: from localhost ([127.0.0.1]:53805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xn7r3-00039t-Jf for submit@debbugs.gnu.org; Sat, 08 Nov 2014 10:23:09 -0500 Received: from eggs.gnu.org ([208.118.235.92]:46127) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xn7r1-00039j-6I for submit@debbugs.gnu.org; Sat, 08 Nov 2014 10:23:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xn7qw-0006p2-4E for submit@debbugs.gnu.org; Sat, 08 Nov 2014 10:23:06 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:56456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xn7qw-0006oy-18 for submit@debbugs.gnu.org; Sat, 08 Nov 2014 10:23:02 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xn7qv-0003k2-0L for bug-gnu-emacs@gnu.org; Sat, 08 Nov 2014 10:23:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xn7qt-0006of-Qw for bug-gnu-emacs@gnu.org; Sat, 08 Nov 2014 10:23:00 -0500 Received: from mail-lb0-x229.google.com ([2a00:1450:4010:c04::229]:46334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xn7qt-0006n2-7p for bug-gnu-emacs@gnu.org; Sat, 08 Nov 2014 10:22:59 -0500 Received: by mail-lb0-f169.google.com with SMTP id 10so4055598lbg.0 for ; Sat, 08 Nov 2014 07:22:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0tKxQHqr6EgPjERO7sYxf/d/JI8xt4bS6i4479SRtfE=; b=F6Dn56nLGwSsISU5Q8mkFJnMKxydwzR/dFJ20rCz8wCVUxLNHDz8ZNVYX8DfNXzkKv i7pCTBD1/ATr9HFG2ulUINBclKtV+OeD57IiK0PNilRmqCPnOxBv1gZnCmAXuGRe9Zhk 7cSO7yxgdGCVt/jYhFG0MrIQrNZHClnhsWxxI8vor9308XwCdeJSIIUhLibSJiBLVs0D 1bb53KLiQTqWvJgMThCwx22GY/i7Id2mqL6UK+F62Iu4tnhs+IP8szfDybUfHjt9/DVf bxhl3KtH6/U4Pb51sUauNOKRcOg7uqh2kGX8ecZaO0lVLzJZGYyQrto6p7wP+pHRkEHi Lmiw== MIME-Version: 1.0 X-Received: by 10.112.54.162 with SMTP id k2mr17838668lbp.63.1415460176725; Sat, 08 Nov 2014 07:22:56 -0800 (PST) Received: by 10.112.202.106 with HTTP; Sat, 8 Nov 2014 07:22:56 -0800 (PST) Date: Sat, 8 Nov 2014 16:22:56 +0100 Message-ID: Subject: Error: Could not reserve dynamic heap area. From: Alexander Shukaev To: bug-gnu-emacs Content-Type: multipart/alternative; boundary=001a11c3eeee070ee805075a81fe X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --001a11c3eeee070ee805075a81fe Content-Type: text/plain; charset=UTF-8 The build enviroment is MinGW-w64 and MSYS2. When I build `emacs-24', Emacs is being configured 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 With this configuration the x64 version is built just fine, but the x86 version build fails with make[2]: Entering directory > '/c/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/.build/i686-w64-mingw32/lisp' > Compiling > /C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/emacs-lisp/macroexp.el > Error: Could not reserve dynamic heap area. I've checked what is called in this case and it seems to be fine at the first glance: #else /* USE_LSB_TAG */ static char * allocate_heap (void) { #ifdef _WIN64 size_t size = 0x4000000000ull; /* start by asking for 32GB */ #else /* We used to start with 2GB here, but on Windows 7 that would leave too little room in the address space for threads started by Windows on our behalf, e.g. when we pop up the file selection dialog. */ size_t size = 0x68000000; /* start by asking for 1.7GB */ <<< This one is used. #endif void *ptr = NULL; while (!ptr && size > 0x00100000) { reserved_heap_size = size; ptr = VirtualAlloc (NULL, get_reserved_heap_size (), MEM_RESERVE, PAGE_NOACCESS); size -= 0x00800000; /* if failed, decrease request by 8MB */ } return ptr; } #endif /* USE_LSB_TAG */ Any ideas? --001a11c3eeee070ee805075a81fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The build enviroment is MinGW-w64 and MSYS2.

When I build `emacs-24', Emacs is being configured wit= h

Should Emacs use the GNU version of malloc? yes
Should Emacs use a relocating allocat= or for buffers? yes
Should Emacs use mmap(2) for buffer allocation? <= /span> no

With this configuration the x64 version = is built just fine, but the x86 version build fails with

make[2]: Entering directory '/c/Users/Haroogan/= Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/.build/i686-w64-mingw32/= lisp'
Compiling /C/Users/Haroogan/Projects/GitHub/MINGW-packages/min= gw-w64-emacs/src/emacs/lisp/emacs-lisp/macroexp.el
Error: Could not rese= rve dynamic heap area.

=C2=A0I've check= ed what is called in this case and it seems to be fine at the first glance:=

#else =C2=A0/* USE_LSB_TAG */
static char *
allocate_heap (void)
<= div>{
#ifdef _WIN64
=C2=A0 size_t= size =3D 0x4000000000ull; /* start by asking for 32GB */
<= div>#else
=C2=A0 /* We used to start with 2GB here, bu= t on Windows 7 that would leave
=C2=A0 =C2=A0 =C2=A0to= o little room in the address space for threads started by
<= div>=C2=A0 =C2=A0 =C2=A0Windows on our behalf, e.g. when we pop up the file= selection
=C2=A0 =C2=A0 =C2=A0dialog. =C2=A0*/
<= /div>
=C2=A0 size_t size =3D 0x68000000; /* start by asking for 1.= 7GB */ <<< This one is used.
#endif
=C2=A0 void *ptr =3D NULL;

=C2=A0 while (!ptr && size > 0x00100000)
<= div>
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 reserved= _heap_size =3D size;
=C2=A0 =C2=A0 =C2=A0 ptr =3D Virt= ualAlloc (NULL,
=C2=A0get_reserved_heap_size (),
=C2=A0MEM_RESERVE,
=C2=A0P= AGE_NOACCESS);
=C2=A0 =C2=A0 =C2=A0 size -=3D 0x008000= 00; /* if failed, decrease request by 8MB */
=C2=A0 = =C2=A0 }

=C2=A0 return ptr;<= /div>
}
#endif /* USE_LSB_TAG */
<= /div>

Any ideas?
--001a11c3eeee070ee805075a81fe-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 08 12:29:28 2014 Received: (at 18995) by debbugs.gnu.org; 8 Nov 2014 17:29:28 +0000 Received: from localhost ([127.0.0.1]:53895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xn9pI-0007i8-9D for submit@debbugs.gnu.org; Sat, 08 Nov 2014 12:29:28 -0500 Received: from mtaout25.012.net.il ([80.179.55.181]:51934) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xn9pE-0007ht-TS for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 12:29:26 -0500 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NEQ00A00DAB3X00@mtaout25.012.net.il> for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 19:24:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEQ002VDDPJ1080@mtaout25.012.net.il>; Sat, 08 Nov 2014 19:24:55 +0200 (IST) Date: Sat, 08 Nov 2014 19:29:08 +0200 From: Eli Zaretskii Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. In-reply-to: X-012-Sender: halo1@inter.net.il To: Alexander Shukaev Message-id: <834mu9r47v.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 8 Nov 2014 16:22:56 +0100 > From: Alexander Shukaev > > When I build `emacs-24', Emacs is being configured 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 > > With this configuration the x64 version is built just fine, but the x86 version > build fails with > > make[2]: Entering directory > '/c/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/.build/i686-w64-mingw32/lisp' > > Compiling > /C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/lisp/emacs-lisp/macroexp.el > > Error: Could not reserve dynamic heap area. > > I've checked what is called in this case and it seems to be fine at the first > glance: Sorry, I don't understand: what part of the allocate_heap function is being run and fails in your case? Does the loop start with 0x4000000000 or with 0x68000000? Does it go all the way through 0x00100000, and each call to VirtualAlloc fails? If so, can you see what error code does VirtualAlloc return? You can accomplish the latter in GDB like this: (gdb) p w32_last_error() Also, does the same command succeed if you run it from the Bash command line? Does it succeed if you run it from the cmd.exe command line? Finally, did you run the build from the Bash command line outside Emacs, or did you run it from inside another Emacs session? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 08 13:17:58 2014 Received: (at 18995) by debbugs.gnu.org; 8 Nov 2014 18:17:58 +0000 Received: from localhost ([127.0.0.1]:53936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnAaD-0003B9-NH for submit@debbugs.gnu.org; Sat, 08 Nov 2014 13:17:58 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:33785) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnAaB-0003Az-VP for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 13:17:56 -0500 Received: by mail-lb0-f169.google.com with SMTP id 10so4131044lbg.14 for <18995@debbugs.gnu.org>; Sat, 08 Nov 2014 10:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qzAH0AGjiW+puKHCURbFhWZwxGDk5iz4dOm58+3d0m8=; b=sxRZUXBirXDZWe8d2SgMkh9DtcuvRID/UJ9r5cOT2DuzWClEYtVzF1cCowQzCalbK0 dU7Ew96vERYwHIb7n3Zpetv+CYNhW47GsPxgtj8ddtRofWqGIG0SB2qdycBt3iZYaUs9 ZHNxwPSqunZ0CL5+EVGXAyb42NGh1FQrKVIoAGh4vYRwPUy5iJ92W5IuZpmrj65wUIi4 9941tRIcDTkD9DPDiunaEqas1SWej5riaEgLhH6X6HAQH5IVaFFB63NN2KyAsQQekLWp OUpP5bt2Mv3bTA+o/BhAnzBWzjNVhmrv2subpmb9LnCpdPJ9tqS3GeBIVRtTRxtS6Ff8 r+lA== MIME-Version: 1.0 X-Received: by 10.152.42.172 with SMTP id p12mr18931462lal.11.1415470675178; Sat, 08 Nov 2014 10:17:55 -0800 (PST) Received: by 10.112.202.106 with HTTP; Sat, 8 Nov 2014 10:17:55 -0800 (PST) In-Reply-To: <834mu9r47v.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> Date: Sat, 8 Nov 2014 19:17:55 +0100 Message-ID: Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. From: Alexander Shukaev To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11c35086c8bff605075cf2f8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c35086c8bff605075cf2f8 Content-Type: text/plain; charset=UTF-8 > > or did you run it from inside another Emacs session? No. Also, does the same command succeed if you run it from the Bash > command line? Does it succeed if you run it from the cmd.exe command > line? No, has nothing to do with it. I've got something amazing/phenomenal here. Read carefully. With "-g -O0" it can reserve memory just fine and everything builds successfully. With "-O3" it fails with the first try, i.e. with the size of 0x68000000 and the corresponding error is: ERROR_NOT_ENOUGH_MEMORY > 8 (0x8) > Not enough storage is available to process this command. Since with "-g -O0" it succeeds, it cannot be debugged with GDB. For "-O3" I used simple `printf' testing. I can test "-O2" if you are interested. What does it smell like? A toolchain bug? --001a11c35086c8bff605075cf2f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
or did you run it from inside another Ema= cs session?

No.

Also, does the same command succeed if you run it from the B= ash
command line?=C2=A0 Does it succeed if you run it from the cmd.exe c= ommand
line?

No, has nothing to do= with it.

I've got something amazing/phenomenal her= e. Read carefully. With "-g -O0" it can reserve memory just fine = and everything builds successfully. With "-O3" it fails with the = first try, i.e. with the size of=C2=A00x68000000 and the corresponding erro= r is:

ERROR_NOT_ENOUGH_MEMORY
8 (0x8= )
Not enough storage is available to process this command.
<= div>
=C2=A0Since with=C2=A0"-g -O0" it succeeds, it= cannot be debugged with GDB. For "-O3" I used simple `printf'= ; testing.

=C2=A0I can test "-O2" = if you are interested.

What does it smell like= ? A toolchain bug?
--001a11c35086c8bff605075cf2f8-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 08 13:31:04 2014 Received: (at 18995) by debbugs.gnu.org; 8 Nov 2014 18:31:04 +0000 Received: from localhost ([127.0.0.1]:53940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnAmu-0003Vj-6b for submit@debbugs.gnu.org; Sat, 08 Nov 2014 13:31:04 -0500 Received: from mtaout24.012.net.il ([80.179.55.180]:53638) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnAmq-0003VF-Sy for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 13:31:02 -0500 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NEQ00F00FSXQO00@mtaout24.012.net.il> for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 20:23:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEQ009G2GFGN980@mtaout24.012.net.il>; Sat, 08 Nov 2014 20:23:40 +0200 (IST) Date: Sat, 08 Nov 2014 20:30:44 +0200 From: Eli Zaretskii Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. In-reply-to: X-012-Sender: halo1@inter.net.il To: Alexander Shukaev Message-id: <83y4rlpmsr.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 8 Nov 2014 19:17:55 +0100 > From: Alexander Shukaev > Cc: 18995@debbugs.gnu.org > > I've got something amazing/phenomenal here. Read carefully. With "-g -O0" it > can reserve memory just fine and everything builds successfully. With "-O3" it > fails with the first try, i.e. with the size of 0x68000000 and the > corresponding error is: > > ERROR_NOT_ENOUGH_MEMORY > 8 (0x8) > Not enough storage is available to process this command. > > Since with "-g -O0" it succeeds, it cannot be debugged with GDB. For "-O3" I > used simple `printf' testing. > > I can test "-O2" if you are interested. Yes, please do. I don't think I ever tried -O3 (and I don't think it's a good idea in Emacs in general). > What does it smell like? A toolchain bug? Could be. What GCC version are you using? Also, when -O3 is used, does it help to declare reserved_heap_size volatile, like this: size_t volatile reserved_heap_size; (You might need to change the extern declaration on w32heap.h as well.) From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 08 13:41:01 2014 Received: (at 18995) by debbugs.gnu.org; 8 Nov 2014 18:41:01 +0000 Received: from localhost ([127.0.0.1]:53955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnAwX-0003kR-3f for submit@debbugs.gnu.org; Sat, 08 Nov 2014 13:41:01 -0500 Received: from mail-lb0-f180.google.com ([209.85.217.180]:47174) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnAwV-0003kK-D0 for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 13:41:00 -0500 Received: by mail-lb0-f180.google.com with SMTP id u10so4043664lbd.25 for <18995@debbugs.gnu.org>; Sat, 08 Nov 2014 10:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X9Vu3u4bTO+IvNzPN8mrQlIyAtEuGWvci48RlARalo0=; b=JC4DLFhaper5bV2onZCCSG8LbzMe9vrNOzKNATpYfNTt4Sv/qlNKgB+IhXES80BjWh ke/F8TURp5/B3X4p0T0CkSnCN0zCTcyvKKRNhTF6HvI+fqEVTOwCyGAL5FNBSJajMfsY u3mNpv07MdFH+ydWoksQY0/H7klf+dMPhxb9OTdqF/xkx6iK1/1B5IXZUHjAr8OcCrJw 2IeNLnMUYACw08o/A4MyQ+0pXodE7XyxkuCaFn+fqXZhgPzWXI8jJXBZtQt7mBSD4bwc tiHjn8qx9gyDqNzc+oJ2XGO3vsM9CLlnbI2YfsavR59hRIXvNLHXfKmN3dOl2+/BKASL 8KXQ== MIME-Version: 1.0 X-Received: by 10.112.73.103 with SMTP id k7mr19045751lbv.41.1415472058560; Sat, 08 Nov 2014 10:40:58 -0800 (PST) Received: by 10.112.202.106 with HTTP; Sat, 8 Nov 2014 10:40:58 -0800 (PST) In-Reply-To: <83y4rlpmsr.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> Date: Sat, 8 Nov 2014 19:40:58 +0100 Message-ID: Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. From: Alexander Shukaev To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11c32ce43d763f05075d454c X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c32ce43d763f05075d454c Content-Type: text/plain; charset=UTF-8 Both "-O2" and "-O1" don't work as well. Only "-O0" works. Could be. What GCC version are you using? Latest: gcc.exe (Rev2, Built by MSYS2 project) 4.9.2 Also, when -O3 is used, does it help to declare reserved_heap_size > volatile, like this: > size_t volatile reserved_heap_size; > (You might need to change the extern declaration on w32heap.h as > well.) Unfortunately, nope. --001a11c32ce43d763f05075d454c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Both "-O2" and "-O1" don't work as= well. Only "-O0" works.

Could be.= =C2=A0 What GCC version are you using?

Late= st:

gcc.exe (Rev2, Built by MSYS2 proj= ect) 4.9.2

Also, when -O3 = is used, does it help to declare reserved_heap_size
volatile, like this:=
=C2=A0
=C2= =A0 size_t volatile reserved_heap_size;
= =C2=A0
(You might need to change the extern de= claration on w32heap.h as
well.)

U= nfortunately, nope.
--001a11c32ce43d763f05075d454c-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 08 13:57:37 2014 Received: (at 18995) by debbugs.gnu.org; 8 Nov 2014 18:57:37 +0000 Received: from localhost ([127.0.0.1]:53959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnBCZ-000491-J9 for submit@debbugs.gnu.org; Sat, 08 Nov 2014 13:57:36 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:52875) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnBCV-00048l-9G for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 13:57:33 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NEQ00500HMY9E00@a-mtaout22.012.net.il> for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 20:57:28 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEQ00513HZS2660@a-mtaout22.012.net.il>; Sat, 08 Nov 2014 20:57:28 +0200 (IST) Date: Sat, 08 Nov 2014 20:57:13 +0200 From: Eli Zaretskii Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. In-reply-to: X-012-Sender: halo1@inter.net.il To: Alexander Shukaev Message-id: <83wq75plkm.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 8 Nov 2014 19:40:58 +0100 > From: Alexander Shukaev > Cc: 18995@debbugs.gnu.org > > Both "-O2" and "-O1" don't work as well. Only "-O0" works. So what, the optimized code goes only once through the loop, and then bails out? If so, what is the value of 'size' when the loop ends? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 08 14:16:24 2014 Received: (at 18995) by debbugs.gnu.org; 8 Nov 2014 19:16:24 +0000 Received: from localhost ([127.0.0.1]:53964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnBUl-0004cs-D7 for submit@debbugs.gnu.org; Sat, 08 Nov 2014 14:16:23 -0500 Received: from mail-la0-f50.google.com ([209.85.215.50]:64570) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnBUi-0004ci-1I for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 14:16:20 -0500 Received: by mail-la0-f50.google.com with SMTP id hz20so5996242lab.9 for <18995@debbugs.gnu.org>; Sat, 08 Nov 2014 11:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8PA8QdGkBH3vjd1gLRUgGz1m8OFQ1VpZxYNJ36JKKeA=; b=JOnBqzkpaO4WqfADpK8GeAcd93/LniUDYBYLzXcyd2m9kkWRyJW2OWZt53ZcZ/G0kt huy1GN1Awn/OXPR8mX0mCXbPrZy6W2NBMzA3CnWp4x+/N2HgrhUKhjoDJ0nwr0JHeX9j wn4utPrESUecfk7SHyEGuq9XZDOBJwmy1IUpzct9fPaJwjqrMIaRIFS9CAgexbJYqCBD Huwj4/qdiVcTJQSk0jHd8JLtOK9UmBs/1F67/bL4g5cgE3vXrk85sCyEyJ+jjN92RBLE TSjodzHZb74pyTm5QYv07kXPTOA+jLClX59Yuugvg6UGpFGv48Htc5+AWB239nXz2Z4t ionw== MIME-Version: 1.0 X-Received: by 10.152.42.226 with SMTP id r2mr19191260lal.29.1415474179059; Sat, 08 Nov 2014 11:16:19 -0800 (PST) Received: by 10.112.202.106 with HTTP; Sat, 8 Nov 2014 11:16:19 -0800 (PST) In-Reply-To: <83wq75plkm.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> Date: Sat, 8 Nov 2014 20:16:19 +0100 Message-ID: Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. From: Alexander Shukaev To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11c35088a1b60605075dc35c X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c35088a1b60605075dc35c Content-Type: text/plain; charset=UTF-8 > > So what, the optimized code goes only once through the loop, and then > bails out? If so, what is the value of 'size' when the loop ends? > OK, so there was one more detail that I forgot to mention. It looks like I also had "-funroll-loops". After removing it, "-O3" works fine too (without "volatile"). I think this is still a toolchain bug because "-O3 -funroll-loops" combination works fine in the x64 build and what's more important --- it *should* work fine. Anyway, maybe it's a good idea to somehow prevent people from passing "-funroll-loops" by filtering it out from "CFLAGS" in "Makefile" for example? --001a11c35088a1b60605075dc35c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So what, the optimized code goes only once throu= gh the loop, and then
bails out?=C2=A0 If so, what is the value of 'size' when the loop e= nds?

OK, so there was on= e more detail that I forgot to mention. It looks like I also had "-fun= roll-loops". After removing it, "-O3" works fine too (withou= t "volatile"). I think this is still a toolchain bug because &quo= t;-O3 -funroll-loops" combination works fine in the x64 build and what= 's more important --- it *should* work fine. Anyway, maybe it's a g= ood idea to somehow prevent people from passing "-funroll-loops" = by filtering it out from "CFLAGS" in "Makefile" for exa= mple?
--001a11c35088a1b60605075dc35c-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 08 14:50:34 2014 Received: (at 18995) by debbugs.gnu.org; 8 Nov 2014 19:50:34 +0000 Received: from localhost ([127.0.0.1]:53985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnC1p-0005Vo-DO for submit@debbugs.gnu.org; Sat, 08 Nov 2014 14:50:34 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:44644) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnC1l-0005Vb-Iu for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 14:50:30 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NEQ00F00K9VBP00@a-mtaout21.012.net.il> for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 21:50:27 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEQ00FFSKG33H80@a-mtaout21.012.net.il>; Sat, 08 Nov 2014 21:50:27 +0200 (IST) Date: Sat, 08 Nov 2014 21:50:13 +0200 From: Eli Zaretskii Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. In-reply-to: X-012-Sender: halo1@inter.net.il To: Alexander Shukaev Message-id: <83vbmppj4a.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 8 Nov 2014 20:16:19 +0100 > From: Alexander Shukaev > Cc: 18995@debbugs.gnu.org > > So what, the optimized code goes only once through the loop, and then > bails out? If so, what is the value of 'size' when the loop ends? > > > OK, so there was one more detail that I forgot to mention. It looks like I also > had "-funroll-loops". After removing it, "-O3" works fine too (without > "volatile"). I think this is still a toolchain bug because "-O3 -funroll-loops" > combination works fine in the x64 build and what's more important --- it > *should* work fine. Anyway, maybe it's a good idea to somehow prevent people > from passing "-funroll-loops" by filtering it out from "CFLAGS" in "Makefile" > for example? Do you understand why -funroll-loops causes the code to fail to work? Because I cannot. Unless I'm missing something, this sounds like a GCC bug. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 08 14:58:09 2014 Received: (at 18995) by debbugs.gnu.org; 8 Nov 2014 19:58:09 +0000 Received: from localhost ([127.0.0.1]:53989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnC9A-0005h7-96 for submit@debbugs.gnu.org; Sat, 08 Nov 2014 14:58:08 -0500 Received: from mail-la0-f52.google.com ([209.85.215.52]:40403) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnC95-0005gs-Hz for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 14:58:04 -0500 Received: by mail-la0-f52.google.com with SMTP id pv20so6045311lab.11 for <18995@debbugs.gnu.org>; Sat, 08 Nov 2014 11:58:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=476fqs2QgZh4idOpV2PKwWBifjCNiVChnf8jAghPJoQ=; b=d7rB/6hVHuhkJRvcPERol6GIbUgpkXCUQ14mWKNsv0XJPAZRMGXx1FAvAQH6MRisze Q/E9e3bHswUf6AlGcRt4/jmGbX4gsLo0WVGi6lhoCjJDVnjLRabFuS9lqVRo4cwgzJWN yD7/pFyt6NUDQW+X7OthACDhOtpn9NA+W3zFdGv8+RvtWRfjgXoI4V0ECrOv8s7gYVPr 05X2vHvGC8memiJuSrgVF45PCGcookh9PcBnMS7iYLDOcc0fhUb7NIVBaFSIZQI11Hos T3Uy7gbsJylDTxc+UdKA5iXBdHe+qV/0t0H+aC+FeG7NVaHaljtOkeFj0RmabiAQ0NbH oTMA== MIME-Version: 1.0 X-Received: by 10.152.27.38 with SMTP id q6mr4263385lag.92.1415476682339; Sat, 08 Nov 2014 11:58:02 -0800 (PST) Received: by 10.112.202.106 with HTTP; Sat, 8 Nov 2014 11:58:02 -0800 (PST) In-Reply-To: <83vbmppj4a.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> Date: Sat, 8 Nov 2014 20:58:02 +0100 Message-ID: Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. From: Alexander Shukaev To: Eli Zaretskii Content-Type: multipart/alternative; boundary=089e0158bdead6bc4305075e58a3 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e0158bdead6bc4305075e58a3 Content-Type: text/plain; charset=UTF-8 > > Do you understand why -funroll-loops causes the code to fail to work? > Because I cannot. Unless I'm missing something, this sounds like a > GCC bug. > I've no idea. For that we would have to look into generated assembly code, but I'd rather leave that for compiler professionals to analyze. Would forward it to GCC guys? And how about filtering this flag for good as I asked earlier? CFLAGS := $(filter-out -funroll-loops,$(CFLAGS)) --089e0158bdead6bc4305075e58a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Do = you understand why -funroll-loops causes the code to fail to work?
Because I cannot.=C2=A0 Unless I'm missing something, this sounds like = a
GCC bug.
=C2=A0
I've no idea.= For that we would have to look into generated assembly code, but I'd r= ather leave that for compiler professionals to analyze. Would forward it to= GCC guys?

And how about filtering this flag for good as I asked earlier?

CFLAGS :=3D $(filter-out= -funroll-loops,$(CFLAGS))
--089e0158bdead6bc4305075e58a3-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 08 15:05:51 2014 Received: (at 18995) by debbugs.gnu.org; 8 Nov 2014 20:05:51 +0000 Received: from localhost ([127.0.0.1]:53993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnCGZ-0005tm-I2 for submit@debbugs.gnu.org; Sat, 08 Nov 2014 15:05:48 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:48583) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnCGU-0005tZ-FE for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 15:05:43 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NEQ00300KYUIN00@a-mtaout20.012.net.il> for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 22:05:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEQ003ZXL5G0B80@a-mtaout20.012.net.il>; Sat, 08 Nov 2014 22:05:41 +0200 (IST) Date: Sat, 08 Nov 2014 22:05:26 +0200 From: Eli Zaretskii Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. In-reply-to: X-012-Sender: halo1@inter.net.il To: Alexander Shukaev Message-id: <83r3xdpiex.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 8 Nov 2014 20:58:02 +0100 > From: Alexander Shukaev > Cc: 18995@debbugs.gnu.org > > Do you understand why -funroll-loops causes the code to fail to work? > > Because I cannot. Unless I'm missing something, this sounds like a > GCC bug. > > > I've no idea. For that we would have to look into generated assembly code, but > I'd rather leave that for compiler professionals to analyze. Would forward it > to GCC guys? It probably does warrant a GCC bug report. > And how about filtering this flag for good as I asked earlier? > > CFLAGS := $(filter-out -funroll-loops,$(CFLAGS)) What for? It's a perfectly legitimate compiler switch, and should work here as well, I think. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 08 15:49:19 2014 Received: (at 18995) by debbugs.gnu.org; 8 Nov 2014 20:49:19 +0000 Received: from localhost ([127.0.0.1]:54006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnCwd-0006yC-Dc for submit@debbugs.gnu.org; Sat, 08 Nov 2014 15:49:16 -0500 Received: from dancol.org ([96.126.100.184]:47883) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnCwY-0006y0-Nd for 18995@debbugs.gnu.org; Sat, 08 Nov 2014 15:49:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=yJ/LW52TyEtRCM218JsJZnVd+7NLlwReW8wDiaE/VZE=; b=gBxfEjXaweTOs9pb5P0dvPY/xDhXi4d3h+FO1voUVSGhq2CwC0APqzwV24E/a0USHNYZWiitWW1SZakmp+t8/FBd5AsHypb3UqLXb2Z1z+EIqfawvVHvR6ClysDo1qMueWvcYBshP0Na6FmWOHtlXNGBF/oBhOCyWAlMhszH5YD+eIGnPXYDhaKuRoZ92qAEiFW5VaFXIWNpDC8ErWjQJtxLtTsEiXGWEv40ps7MBqqEE20TVruxK3X7TMkiEea6OaTSjLuqRxRJsSHmtSy3mpPp9SpPl5xBUSGuU989SRFB+CBU7cU9QLjIkefLGwjY+jg3MfvudyMXTmiUle+I7g==; Received: from [81.168.70.173] (helo=[192.168.1.11]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1XnCwW-0005bZ-NS; Sat, 08 Nov 2014 12:49:08 -0800 Message-ID: <545E81BD.8070904@dancol.org> Date: Sat, 08 Nov 2014 20:49:01 +0000 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Eli Zaretskii , Alexander Shukaev Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> In-Reply-To: <83r3xdpiex.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q4Hx5QnF0deGBP6QtPS4Uc54oxrQothp8" X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q4Hx5QnF0deGBP6QtPS4Uc54oxrQothp8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/08/2014 08:05 PM, Eli Zaretskii wrote: >> Date: Sat, 8 Nov 2014 20:58:02 +0100 >> From: Alexander Shukaev >> Cc: 18995@debbugs.gnu.org >> >> Do you understand why -funroll-loops causes the code to fail to wo= rk? >> =20 >> Because I cannot. Unless I'm missing something, this sounds like a= >> GCC bug. >> =20 >> >> I've no idea. For that we would have to look into generated assembly c= ode, but >> I'd rather leave that for compiler professionals to analyze. Would for= ward it >> to GCC guys? >=20 > It probably does warrant a GCC bug report. >=20 >> And how about filtering this flag for good as I asked earlier? >> >> CFLAGS :=3D $(filter-out -funroll-loops,$(CFLAGS)) >=20 > What for? It's a perfectly legitimate compiler switch, and should > work here as well, I think. Agreed on not filtering it out. Alexander, does it help to add explicit debug output (say, fprintf to stderr) on each iteration of the loop? If not, can you compare the debug output from the version with -funroll-loops to the one without, to see whether we're making the same sequence of VirtualAlloc calls? If they're the same, maybe it's not the loop that's broken, but the address space layout. --q4Hx5QnF0deGBP6QtPS4Uc54oxrQothp8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUXoG9AAoJEN4WImmbpWBlqGwP/0Cfdl8byN0u9+nCjdWnxzGE B3+F6MX+74XMJPXFDt+DkTCmmXEkOMIEXZc8RtdbQc7TxZFjtLCCfMBxaxQqg8UX /fSm8R28oeAr9B1GV0IxOZrvt7SVoddY2iDZAnLpQMpe0nQuGkKQZtWLmWAx9pDz tLGhDeGQqExU5pBrdnk7FF4XsUcljKrr0f2B/dRHAMvUQhPuxY3lB9mqZH4pqpWH iKcz+TVesNNcflO6v2SLXDqoqOI6kSuraJVIhEW8XL34Z1CDzGZtC8GZQ2LntJ7q FMAPd9XKegCFi61BF5I6PHp2+RJJxNHIe7K96b1fGVIlKnkLd/EKmUyoNMZWL+Fd ifvk5cXy/prxzHLuQF9M+RuUldOU009LGT5COpKd7xUOzuYisR8bxmiiUoHK0NY1 IzlVkLw//v61BJTajauJdcwqgf1D8aFZs88FG9szSDibWu63cxu5qrunpjYrczvv pTk4qzlHdPlNwKb1EdqIy2vRAcNSuRFTSJeCjwk1G5NfF1Lvg4mHRXb3l4qnT4nS TsrQ3vkpzgTLCBw7uVPCyVG/vXXyaTHz7y2Yg3+BFOAHeMl6zp/Mh9NuavmSuvh/ APalMzLCTCTjTriAv9qkAIPZsLt5L+H5IhdippusvDPtqWBXVLd3s7nOcUHHvmSw VN/Gy1WpoOx/pLdGtsW+ =n1aU -----END PGP SIGNATURE----- --q4Hx5QnF0deGBP6QtPS4Uc54oxrQothp8-- From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 09 11:12:37 2014 Received: (at 18995-done) by debbugs.gnu.org; 9 Nov 2014 16:12:37 +0000 Received: from localhost ([127.0.0.1]:54932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnV6S-00029p-H3 for submit@debbugs.gnu.org; Sun, 09 Nov 2014 11:12:37 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:65534) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnV6N-00029c-Pm for 18995-done@debbugs.gnu.org; Sun, 09 Nov 2014 11:12:33 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NES00E004ZZX600@a-mtaout20.012.net.il> for 18995-done@debbugs.gnu.org; Sun, 09 Nov 2014 18:12:29 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NES00EB850SRU20@a-mtaout20.012.net.il>; Sun, 09 Nov 2014 18:12:29 +0200 (IST) Date: Sun, 09 Nov 2014 18:12:16 +0200 From: Eli Zaretskii Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. In-reply-to: <545E81BD.8070904@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <83egtcpd3z.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> <545E81BD.8070904@dancol.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18995-done Cc: haroogan@gmail.com, 18995-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 08 Nov 2014 20:49:01 +0000 > From: Daniel Colascione > CC: 18995@debbugs.gnu.org > > Alexander, does it help to add explicit debug output (say, fprintf to > stderr) on each iteration of the loop? I'm not Alexander, but I can answer that question now: no, it doesn't help. The loop is still executed only once, even if it calls fprintf. > If not, can you compare the debug output from the version with > -funroll-loops to the one without, to see whether we're making the > same sequence of VirtualAlloc calls? If they're the same, maybe it's > not the loop that's broken, but the address space layout. There's nothing wrong with the address space, and there's nothing wrong with GCC, either. What we have here is a genuine bug in our code, albeit one that is subtle, and also very hard to actually reproduce in real life. It looked like a GCC bug at first, but as I tried to modify the source and look at the effect of that on the generated code, it finally dawned on me: GCC's loop-unrolling code simply correctly calculated that with the initial value of 0x68000000 and decrement of 0x00800000, the value of 'size' in the loop will never be less than 0x00100000, due to wraparound in the subtraction of unsigned values. So what we have here is a potentially infinite loop, i.e. "undefined behavior". Given that, it is justified for GCC to give us what we deserve, i.e. a loop "unrolled" by executing its body only once. I present the disassembly below, for the curious, and it's clear that there's no loop there, and also the value of 'size' is never tested at all, since GCC decided that the condition 'size > 0x00100000' is always true. Of course, in reality this "infinite" loop will always be finite, since a real live system will always find more than 8MB of free address space to reserve. Unless someone deliberately reserved a lot of the address space just to cause Emacs hit this problem, that is. I installed a trivial fix on the emacs-24 branch, and I'm closing this bug. Here's the disassembly of the original code, as compiled with "-funroll-loops" (it is for init_heap, because allocate_heap is inlined in it): (gdb) disassemble init_heap Dump of assembler code for function init_heap: 0x0122f1fc <+0>: push %ebx 0x0122f1fd <+1>: sub $0x18,%esp 0x0122f200 <+4>: movl $0x0,(%esp) 0x0122f207 <+11>: call 0x1277184 0x0122f20c <+16>: sub $0x4,%esp 0x0122f20f <+19>: add 0x3c(%eax),%eax 0x0122f212 <+22>: mov %eax,0x4(%esp) 0x0122f216 <+26>: movl $0x14c1cd0,(%esp) 0x0122f21d <+33>: call 0x11c4cb5 0x0122f222 <+38>: mov %eax,0x154abd4 0x0122f227 <+43>: cmpl $0x0,0x1533cf0 0x0122f22e <+50>: je 0x122f28b 0x0122f230 <+52>: mov $0x68000000,%ecx 0x0122f235 <+57>: mov %ecx,0x15422a0 0x0122f23b <+63>: movl $0x1,0xc(%esp) 0x0122f243 <+71>: movl $0x2000,0x8(%esp) 0x0122f24b <+79>: mov %ecx,0x4(%esp) 0x0122f24f <+83>: movl $0x0,(%esp) 0x0122f256 <+90>: call 0x12775cc 0x0122f25b <+95>: sub $0x10,%esp 0x0122f25e <+98>: mov %eax,0x15422ac 0x0122f263 <+103>: test %eax,%eax <<<<<<<<<<< 0x0122f265 <+105>: jne 0x122f27f <<<<<<<<<<< 0x0122f267 <+107>: movl $0x14c1cd8,(%esp) <<<<<<<<<<< 0x0122f26e <+114>: call 0x122f0e0 <<<<<<<<<<< 0x0122f273 <+119>: movl $0x1,(%esp) <<<<<<<<<<< 0x0122f27a <+126>: call 0x1276948 <<<<<<<<<<< 0x0122f27f <+131>: mov %eax,0x15422a8 0x0122f284 <+136>: mov %eax,0x15422a4 0x0122f289 <+141>: jmp 0x122f2bc 0x0122f28b <+143>: mov 0xc(%eax),%ebx 0x0122f28e <+146>: movl $0x0,(%esp) 0x0122f295 <+153>: call 0x1277184 0x0122f29a <+158>: sub $0x4,%esp 0x0122f29d <+161>: add %ebx,%eax 0x0122f29f <+163>: mov %eax,0x15422ac 0x0122f2a4 <+168>: mov %eax,0x15422a8 0x0122f2a9 <+173>: mov %eax,0x15422a4 0x0122f2ae <+178>: mov 0x154abd4,%eax 0x0122f2b3 <+183>: mov 0x8(%eax),%edx 0x0122f2b6 <+186>: mov %edx,0x15422a0 0x0122f2bc <+192>: call 0x1201f1d 0x0122f2c1 <+197>: add $0x18,%esp 0x0122f2c4 <+200>: pop %ebx 0x0122f2c5 <+201>: ret End of assembler dump. Look, ma: no loop! From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 09 11:30:28 2014 Received: (at 18995) by debbugs.gnu.org; 9 Nov 2014 16:30:28 +0000 Received: from localhost ([127.0.0.1]:54938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVNj-0002bp-HJ for submit@debbugs.gnu.org; Sun, 09 Nov 2014 11:30:28 -0500 Received: from mail-out.m-online.net ([212.18.0.10]:57430) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVNg-0002bg-BZ for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 11:30:25 -0500 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3jbLRM2cyyz3hjdY; Sun, 9 Nov 2014 17:30:23 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 3jbLRM18nBzvh1v; Sun, 9 Nov 2014 17:30:23 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new, port 10024) with ESMTP id 44dE9vndlKLY; Sun, 9 Nov 2014 17:30:21 +0100 (CET) X-Auth-Info: bKl7XV0eyMRfXg7Nnkxc/Q2UZSFZO08ba7WFI9AW2MJ+RTGkAo6wV9RYFy+IN2yZ Received: from igel.home (ppp-93-104-154-215.dynamic.mnet-online.de [93.104.154.215]) by mail.mnet-online.de (Postfix) with ESMTPA; Sun, 9 Nov 2014 17:30:21 +0100 (CET) Received: by igel.home (Postfix, from userid 1000) id 8518C2C2637; Sun, 9 Nov 2014 17:30:21 +0100 (CET) From: Andreas Schwab To: 18995@debbugs.gnu.org Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> <545E81BD.8070904@dancol.org> <83egtcpd3z.fsf@gnu.org> X-Yow: I've got an IDEA!! Why don't I STARE at you so HARD, you forget your SOCIAL SECURITY NUMBER!! Date: Sun, 09 Nov 2014 17:30:21 +0100 In-Reply-To: <83egtcpd3z.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Nov 2014 18:12:16 +0200") Message-ID: <87vbmoqqua.fsf@igel.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18995 Cc: eliz@gnu.org, haroogan@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > Given that, it is justified for GCC to give us what we deserve, i.e. a > loop "unrolled" by executing its body only once. I present the > disassembly below, for the curious, and it's clear that there's no > loop there, and also the value of 'size' is never tested at all, since > GCC decided that the condition 'size > 0x00100000' is always true. But if you replace 'size > 0x00100000' with true, you get a loop that is conditionalized by '!ptr', which depends on the execution of the loop body. Why would it be correct to execute the loop only once, unconditionally? Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 09 11:30:43 2014 Received: (at 18995-done) by debbugs.gnu.org; 9 Nov 2014 16:30:43 +0000 Received: from localhost ([127.0.0.1]:54941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVNy-0002cK-Af for submit@debbugs.gnu.org; Sun, 09 Nov 2014 11:30:42 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:63436) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVNv-0002cA-Ph for 18995-done@debbugs.gnu.org; Sun, 09 Nov 2014 11:30:40 -0500 Received: by mail-lb0-f169.google.com with SMTP id 10so4835610lbg.28 for <18995-done@debbugs.gnu.org>; Sun, 09 Nov 2014 08:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yr8No7vTr75acK/TRZ0TBJuWU7zH6FZhtHzYdAPE7Pk=; b=JEsCluW3mZjMh2iGjgySzepYvszjkdIkhrpFEK7EDMSuObyTvlWBCRopggOh+GXkEh 5JRX7ws6EIJSHZ2HpJI3j0t1weqTHJbwB5wWBbzZGtM/Ck9s9YTyJvM6m6ZtY/U7KgqF o6hBpU8ddSxB3gZQBPWS0KzYvYxWx9ahwjaJMVNJKhHnhE/bqIeY5xDhvr6TQO8zXOn4 6OHyueks9fH5TMFnwVg9ZhpFxNl1fMliTYv4aS4CqmRYzuNDiRxuB9rttxr/DddaPP99 2UOdhfvfF3aUIzFihFQmQoeBUC5ITLHSZrsMTSc6UHNRSRPi7AgWQP4+LxZNSrrG6eTK fhHw== MIME-Version: 1.0 X-Received: by 10.152.22.135 with SMTP id d7mr24271156laf.46.1415550638537; Sun, 09 Nov 2014 08:30:38 -0800 (PST) Received: by 10.112.202.106 with HTTP; Sun, 9 Nov 2014 08:30:38 -0800 (PST) In-Reply-To: <545F94E4.5060102@dancol.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> <545E81BD.8070904@dancol.org> <83egtcpd3z.fsf@gnu.org> <545F94E4.5060102@dancol.org> Date: Sun, 9 Nov 2014 17:30:38 +0100 Message-ID: Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. From: Alexander Shukaev To: Daniel Colascione Content-Type: multipart/alternative; boundary=089e0158b9c6f8c29305076f9054 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18995-done Cc: Eli Zaretskii , 18995-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e0158b9c6f8c29305076f9054 Content-Type: text/plain; charset=UTF-8 > > How can this be a bug in our code? Wraparound of unsigned values is > well-defined. True, it is well-defined, but it was not intended for sure, hence it's a 100% bug. Eli's term of "undefined behavior" was an exaggeration I think. I don't think the compiler is justified in making this optimization. > Since when is an infinite loop undefined behavior? GCC has no right to > alter program semantics in this case, loop unrolling or no. I would agree here, throwing out wrapped loop is just too much even though such loop was unintended. GCC should have either left it alone since it is infinite or make a warning. I think this case is still worth showing to GCC developers. --089e0158b9c6f8c29305076f9054 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How can this be a bug in our code? Wrapar= ound of unsigned values is
well-defined.

True, it is well-defined, but it was not intended for sure, hence it's= a 100% bug. Eli's term of "undefined behavior" was an exagge= ration I think.

I don't think the compiler is justified in m= aking this optimization.
Since when is an infinite loop undefined behavi= or? GCC has no right to
alter program semantics in this case, loop unrol= ling or no.

I would agree here, throwing out wrapped loop is just too much= even though such loop was unintended. GCC should have either left it alone= since it is infinite or make a warning. I think this case is still worth s= howing to GCC developers.
--089e0158b9c6f8c29305076f9054-- From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 09 11:35:38 2014 Received: (at 18995) by debbugs.gnu.org; 9 Nov 2014 16:35:38 +0000 Received: from localhost ([127.0.0.1]:54948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVSh-0002ju-Ep for submit@debbugs.gnu.org; Sun, 09 Nov 2014 11:35:37 -0500 Received: from mail-out.m-online.net ([212.18.0.9]:58105) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVSe-0002jl-Si for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 11:35:33 -0500 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3jbLYJ1sVBz3hjRJ; Sun, 9 Nov 2014 17:35:32 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 3jbLYH74qZzvh1t; Sun, 9 Nov 2014 17:35:31 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new, port 10024) with ESMTP id u8JYoVT801kj; Sun, 9 Nov 2014 17:35:31 +0100 (CET) X-Auth-Info: 2y94FQduUG0ru9UJap0ZLSF505rnfb7wTZXtT9/sm4qrsnOEDh6zWZ3+BM/X42wO Received: from igel.home (ppp-93-104-154-215.dynamic.mnet-online.de [93.104.154.215]) by mail.mnet-online.de (Postfix) with ESMTPA; Sun, 9 Nov 2014 17:35:31 +0100 (CET) Received: by igel.home (Postfix, from userid 1000) id EB9582C2637; Sun, 9 Nov 2014 17:35:30 +0100 (CET) From: Andreas Schwab To: 18995@debbugs.gnu.org Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> <545E81BD.8070904@dancol.org> <83egtcpd3z.fsf@gnu.org> X-Yow: While my BRAINPAN is being refused service in BURGER KING, Jesuit priests are DATING CAREER DIPLOMATS!! Date: Sun, 09 Nov 2014 17:35:30 +0100 In-Reply-To: <83egtcpd3z.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Nov 2014 18:12:16 +0200") Message-ID: <87r3xcqqlp.fsf@igel.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18995 Cc: eliz@gnu.org, haroogan@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > It looked like a GCC bug at first, but as I tried to modify the source > and look at the effect of that on the generated code, it finally > dawned on me: GCC's loop-unrolling code simply correctly calculated > that with the initial value of 0x68000000 and decrement of 0x00800000, > the value of 'size' in the loop will never be less than 0x00100000, > due to wraparound in the subtraction of unsigned values. Before wraping around, size will become zero, which is definitely less than 0x00100000. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 09 11:39:35 2014 Received: (at 18995) by debbugs.gnu.org; 9 Nov 2014 16:39:36 +0000 Received: from localhost ([127.0.0.1]:54952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVWZ-0002pq-Lt for submit@debbugs.gnu.org; Sun, 09 Nov 2014 11:39:35 -0500 Received: from mail-la0-f45.google.com ([209.85.215.45]:34367) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVWX-0002pg-Bi for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 11:39:33 -0500 Received: by mail-la0-f45.google.com with SMTP id pn19so6592199lab.32 for <18995@debbugs.gnu.org>; Sun, 09 Nov 2014 08:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8SKXEyNgL2PRGmwrR/HcSIwikZvLFJ3OIzRmFJdJxNs=; b=uULxfIhU02qXVMXQ8eENLBwiUCgYIB9zqpA8i9dh629tAN2rRUsNrBDNqmwYl6HzJH 9Voy2OR+X/tyQjUtfAfTT+ZjdzqLLQzk5WwcXLdaYVwDSumVtf4/qaKDqmCBxIjXE7cw Y0YCuFjSqIwQ+D8I5dYWSwqwHCBnEgAoxp9SeKYvybU5lQzX9kwZ+cXNyIsUbfU4QOAn H+MoXFnIsaL9ocszIKqCkMH4fGJFKrMdm4Pf93HSFfYggZ9V6d/4lAz+5IVKqEvM5e/c 7J7BMTP4LFETRwI779oL7zhK/X33FsHj4SnfF1UbjXp1aydWDH+3wfqAxMRjHBdFr9ye zO+w== MIME-Version: 1.0 X-Received: by 10.112.73.103 with SMTP id k7mr24439389lbv.41.1415551172441; Sun, 09 Nov 2014 08:39:32 -0800 (PST) Received: by 10.112.202.106 with HTTP; Sun, 9 Nov 2014 08:39:32 -0800 (PST) In-Reply-To: <87r3xcqqlp.fsf@igel.home> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> <545E81BD.8070904@dancol.org> <83egtcpd3z.fsf@gnu.org> <87r3xcqqlp.fsf@igel.home> Date: Sun, 9 Nov 2014 17:39:32 +0100 Message-ID: Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. From: Alexander Shukaev To: 18995@debbugs.gnu.org Content-Type: multipart/alternative; boundary=001a11c32ce4cb7d3505076fb044 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18995 Cc: Eli Zaretskii , dancol@dancol.org, Andreas Schwab X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c32ce4cb7d3505076fb044 Content-Type: text/plain; charset=UTF-8 Guys, don't forget one important detail, that this happens only in 32-bit build. 64-bit does not have this problem. --001a11c32ce4cb7d3505076fb044 Content-Type: text/html; charset=UTF-8
Guys, don't forget one important detail, that this happens only in 32-bit build. 64-bit does not have this problem.
--001a11c32ce4cb7d3505076fb044-- From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 09 11:40:34 2014 Received: (at 18995) by debbugs.gnu.org; 9 Nov 2014 16:40:34 +0000 Received: from localhost ([127.0.0.1]:54956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVXW-0002rT-0p for submit@debbugs.gnu.org; Sun, 09 Nov 2014 11:40:34 -0500 Received: from dancol.org ([96.126.100.184]:52900) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVXP-0002rH-H8 for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 11:40:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=if7JHdm1J3exOWywr3uSGuCmj3ZYz5ANcBN3sL4javg=; b=ZMlB9xZk+9YT+JRna6OCqjQ9jKypjZWqWw8DR1CRz3Ft9q/U4t4DRuyWiW2anGjyL9aVXwvKzin55H1O3WduoUbnZcIHgu6aNelSTnlhUgDgg/reBMt7Dpe4nVFckhqd8WlZx9LhKNMCc50kyYjUOtJI5NwILvPn8e2IkvHzKlbC/M5V3rxjjjqvQzqC/zrokN/44bfrKVA51v2svOYbeExAG0qLeWDQrJSB/zKg16QkYM/FSqSlGdqyGhytmGDYxf/HDbrnDmKSQ2NqOTkYamD0FLQCdhDwpKWeHH4993oknvPi8XVkbhyEsQKXaz1BX6jHu9Bsl4iF5Z1m6CveWA==; Received: from [81.168.70.173] (helo=[192.168.1.11]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1XnVXN-0002p7-Dl; Sun, 09 Nov 2014 08:40:25 -0800 Message-ID: <545F98F1.5000906@dancol.org> Date: Sun, 09 Nov 2014 16:40:17 +0000 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: 18995@debbugs.gnu.org Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> <545E81BD.8070904@dancol.org> <83egtcpd3z.fsf@gnu.org> <545F94E4.5060102@dancol.org> <837fz4pc4o.fsf@gnu.org> In-Reply-To: <837fz4pc4o.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e71xFiISw5SCnd0LvGsa8muwfEBGGkPh5" X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 18995 Cc: Eli Zaretskii , haroogan@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e71xFiISw5SCnd0LvGsa8muwfEBGGkPh5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/09/2014 04:33 PM, Eli Zaretskii wrote: > Why off-list? User error. Re-adding the list. >> Date: Sun, 09 Nov 2014 16:23:00 +0000 >> From: Daniel Colascione >> CC: haroogan@gmail.com >> >>> There's nothing wrong with the address space, and there's nothing >>> wrong with GCC, either. What we have here is a genuine bug in our >>> code, albeit one that is subtle, and also very hard to actually >>> reproduce in real life. >> >> How can this be a bug in our code? >=20 > Because whoever wrote that loop intended it to stop and bail out at > 0x00100000. And that cannot happen with unsigned subtraction. Sure. And the fix you installed is good, but the bug shouldn't have caused GCC to reduce the loop to one iteration. >>> It looked like a GCC bug at first, but as I tried to modify the sourc= e >>> and look at the effect of that on the generated code, it finally >>> dawned on me: GCC's loop-unrolling code simply correctly calculated >>> that with the initial value of 0x68000000 and decrement of 0x00800000= , >>> the value of 'size' in the loop will never be less than 0x00100000, >>> due to wraparound in the subtraction of unsigned values. So what we >>> have here is a potentially infinite loop, i.e. "undefined behavior". >> >> I don't think the compiler is justified in making this optimization. >> Since when is an infinite loop undefined behavior? GCC has no right to= >> alter program semantics in this case, loop unrolling or no. >=20 > OK, I'm not a C Standard lawyer, so I won't argue here. It's enough > for me to know that the trivial fix I installed makes the code work > even under -funroll-loops, and that it fixes a real problem in our > code. Sure, as well as exposing one in GCC. --e71xFiISw5SCnd0LvGsa8muwfEBGGkPh5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUX5jxAAoJEN4WImmbpWBl9gAP/05ADliGErFrfTFCFjgfDANt 2GunWsBj/Yanijng77lHxyFLs6MY/LFi8i1OSF8wFLRZW9NPeoP2K8iVHhDsJ/cX 3bIl1pAvjDSzmLDc83F4ENnynaxWPkNTtqcF9hGqWiICAHaqhKwDtXa3oB++Roh8 7Ah64EdV6SNkhKNs7BNcaDFWSqEgKrqeSvK32RCZ5tdeklTWyvbISmbH1KpGErTI UgRrzUUOrP5FDAHdMxJ4zF0UQ9B3yq9QCJ8ixaXHRLCBMpTVyLWhwBii6K8JAXhl /4CoeVccBB5tCAAxl4aahYbs/MYZdfy7tp26l0AAfx7YAHXLPpEHfcAKS309OW4I BuFYBIAkRpjPPiihphyrqc/QBF07ZbSR/Ib+GoJG5FnM0yg6VImMflKqYwDtwGrb 6lme/DOJGw7GsEpm1x7eg+Suia+Rejg2mb7MjWXhR8JvmPkNf21Y6cwNbccV4K8k z6Qt5TEyy5IEKGK00KQ709gGdhkA8sz/Eo7PzSOf2YEH3eP9Z5xa1Biq1UeRHjnh MXpcN/Pk9v1YaLoQDfZn+gDw1E5+WuGSdMiVEo/SAd5YTrT8gwGoBTd5FYg8I6et 6HlplyxGFt9oaiUd+wKMAMORT0PdTa+1l6BRyJT47eRJVzY/tcOak8+AJJmGpJZw QxDavgtc5jBOdF/9ASum =2pyV -----END PGP SIGNATURE----- --e71xFiISw5SCnd0LvGsa8muwfEBGGkPh5-- From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 09 11:47:17 2014 Received: (at 18995) by debbugs.gnu.org; 9 Nov 2014 16:47:17 +0000 Received: from localhost ([127.0.0.1]:54964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVe0-000322-Ie for submit@debbugs.gnu.org; Sun, 09 Nov 2014 11:47:16 -0500 Received: from mtaout25.012.net.il ([80.179.55.181]:34642) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVdy-00031s-9A for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 11:47:15 -0500 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NES00C006BHSR00@mtaout25.012.net.il> for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 18:42:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NES009J16FABP30@mtaout25.012.net.il>; Sun, 09 Nov 2014 18:42:46 +0200 (IST) Date: Sun, 09 Nov 2014 18:47:00 +0200 From: Eli Zaretskii Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. In-reply-to: <87vbmoqqua.fsf@igel.home> X-012-Sender: halo1@inter.net.il To: Andreas Schwab Message-id: <834mu8pbi3.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> <545E81BD.8070904@dancol.org> <83egtcpd3z.fsf@gnu.org> <87vbmoqqua.fsf@igel.home> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org, haroogan@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Andreas Schwab > Cc: eliz@gnu.org, haroogan@gmail.com > Date: Sun, 09 Nov 2014 17:30:21 +0100 > > Eli Zaretskii writes: > > > Given that, it is justified for GCC to give us what we deserve, i.e. a > > loop "unrolled" by executing its body only once. I present the > > disassembly below, for the curious, and it's clear that there's no > > loop there, and also the value of 'size' is never tested at all, since > > GCC decided that the condition 'size > 0x00100000' is always true. > > But if you replace 'size > 0x00100000' with true, you get a loop that is > conditionalized by '!ptr', which depends on the execution of the loop > body. Why would it be correct to execute the loop only once, > unconditionally? Feel free to report this as a GCC bug, if you think that's what it is. All I can tell is that the same behavior is present in 3 different GCC releases from 3 different major versions. In any case, I think the original code had a subtle bug, in that the comparison of 'size' didn't do what the author intended. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 09 11:50:00 2014 Received: (at 18995) by debbugs.gnu.org; 9 Nov 2014 16:50:01 +0000 Received: from localhost ([127.0.0.1]:54969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVge-00035u-E2 for submit@debbugs.gnu.org; Sun, 09 Nov 2014 11:50:00 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:58554) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVgb-00035k-Q5 for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 11:49:58 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NES00G006G6V100@a-mtaout23.012.net.il> for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 18:49:56 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NES00G8R6R8QH90@a-mtaout23.012.net.il>; Sun, 09 Nov 2014 18:49:56 +0200 (IST) Date: Sun, 09 Nov 2014 18:49:44 +0200 From: Eli Zaretskii Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. In-reply-to: X-012-Sender: halo1@inter.net.il To: Alexander Shukaev Message-id: <83389spbdj.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> <545E81BD.8070904@dancol.org> <83egtcpd3z.fsf@gnu.org> <87r3xcqqlp.fsf@igel.home> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org, dancol@dancol.org, schwab@linux-m68k.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 9 Nov 2014 17:39:32 +0100 > From: Alexander Shukaev > Cc: Eli Zaretskii , dancol@dancol.org, Andreas Schwab > > Guys, don't forget one important detail, that this happens only in 32-bit > build. 64-bit does not have this problem. Sheer luck: the first call to VirtualAlloc succeeds because it asks for an amount that is much smaller than the 64-bit address space. It worked for me in 32 bits for the same reason. The problem only rears its ugly head when the first call to VirtualAlloc fails. Then we need more iterations, which don't happen. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 09 11:53:29 2014 Received: (at 18995) by debbugs.gnu.org; 9 Nov 2014 16:53:29 +0000 Received: from localhost ([127.0.0.1]:54988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVk0-0003CA-O9 for submit@debbugs.gnu.org; Sun, 09 Nov 2014 11:53:28 -0500 Received: from mail-lb0-f174.google.com ([209.85.217.174]:62725) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnVjy-0003By-St for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 11:53:27 -0500 Received: by mail-lb0-f174.google.com with SMTP id p9so1559057lbv.33 for <18995@debbugs.gnu.org>; Sun, 09 Nov 2014 08:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wifh8XIi1bJLx4uI8P0G8Di5FVoWzuMlvTJEdfwhbpA=; b=Br5BN9O0ktEm2MQz8NA1mPiNJNrC7Zh8yrImnr9tEN75PUcBpM5msQklP/73Q0c5Zy d/vipbOT8Sa7lJTKV2TSIig6D2ffwkYofGI3WWGUGFk7zaNBn3L0cDxizLpkpiJwrkYC PyNsKZuwk2ys7nWxckol3TdpJBqVtMVBgjeeTiVBgTJtacok86Kimzg/fhm1xz1BbmsK /cOXcxGtT6e1wyDEquNDd2ZrWT7Tu0q+avyDv0CrcISvU57hRUR8PNIyOUVvVRdSlWk0 ZDnIrl5gQ9ibqcmghxLRgP4q1Rk/A3v59EgKilW2136H2RwjfNAi7M6HiP2u998nEtbg iEvA== MIME-Version: 1.0 X-Received: by 10.152.6.41 with SMTP id x9mr3042662lax.95.1415552005911; Sun, 09 Nov 2014 08:53:25 -0800 (PST) Received: by 10.112.202.106 with HTTP; Sun, 9 Nov 2014 08:53:25 -0800 (PST) In-Reply-To: <83389spbdj.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> <545E81BD.8070904@dancol.org> <83egtcpd3z.fsf@gnu.org> <87r3xcqqlp.fsf@igel.home> <83389spbdj.fsf@gnu.org> Date: Sun, 9 Nov 2014 17:53:25 +0100 Message-ID: Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. From: Alexander Shukaev To: Eli Zaretskii Content-Type: multipart/alternative; boundary=089e0141a9a2793a2205076fe264 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org, dancol@dancol.org, schwab@linux-m68k.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e0141a9a2793a2205076fe264 Content-Type: text/plain; charset=UTF-8 > > Sheer luck: the first call to VirtualAlloc succeeds because it asks > for an amount that is much smaller than the 64-bit address space. > 32 GB is not that small. I have only 8 GB on my current car... --089e0141a9a2793a2205076fe264 Content-Type: text/html; charset=UTF-8
Sheer luck: the first call to VirtualAlloc succeeds because it asks
for an amount that is much smaller than the 64-bit address space.

32 GB is not that small. I have only 8 GB on my current car...
--089e0141a9a2793a2205076fe264-- From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 09 12:15:18 2014 Received: (at 18995) by debbugs.gnu.org; 9 Nov 2014 17:15:19 +0000 Received: from localhost ([127.0.0.1]:55034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnW54-0003kB-Uq for submit@debbugs.gnu.org; Sun, 09 Nov 2014 12:15:18 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:53657) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnW52-0003k2-G7 for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 12:15:13 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NES00I007SFQR00@a-mtaout22.012.net.il> for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 19:15:11 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NES00IUD7XAHZ40@a-mtaout22.012.net.il>; Sun, 09 Nov 2014 19:15:11 +0200 (IST) Date: Sun, 09 Nov 2014 19:14:58 +0200 From: Eli Zaretskii Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. In-reply-to: <87r3xcqqlp.fsf@igel.home> X-012-Sender: halo1@inter.net.il To: Andreas Schwab Message-id: <831tpcpa7h.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> <545E81BD.8070904@dancol.org> <83egtcpd3z.fsf@gnu.org> <87r3xcqqlp.fsf@igel.home> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org, haroogan@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Andreas Schwab > Cc: eliz@gnu.org, haroogan@gmail.com > Date: Sun, 09 Nov 2014 17:35:30 +0100 > > Eli Zaretskii writes: > > > It looked like a GCC bug at first, but as I tried to modify the source > > and look at the effect of that on the generated code, it finally > > dawned on me: GCC's loop-unrolling code simply correctly calculated > > that with the initial value of 0x68000000 and decrement of 0x00800000, > > the value of 'size' in the loop will never be less than 0x00100000, > > due to wraparound in the subtraction of unsigned values. > > Before wraping around, size will become zero, which is definitely less > than 0x00100000. Right, so it could be pure GCC bug after all. For the record, the problem also goes away if 'size' is declared ptrdiff_t, and nothing else is changed. So whatever the reason, it definitely is somehow related to unsigned arithmetics. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 09 12:18:03 2014 Received: (at 18995) by debbugs.gnu.org; 9 Nov 2014 17:18:03 +0000 Received: from localhost ([127.0.0.1]:55038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnW7n-0003os-4f for submit@debbugs.gnu.org; Sun, 09 Nov 2014 12:18:03 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:42024) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnW7l-0003oS-4R for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 12:18:01 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NES00E007XTMZ00@mtaout29.012.net.il> for 18995@debbugs.gnu.org; Sun, 09 Nov 2014 19:16:23 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NES00C5M7ZAM420@mtaout29.012.net.il>; Sun, 09 Nov 2014 19:16:23 +0200 (IST) Date: Sun, 09 Nov 2014 19:17:47 +0200 From: Eli Zaretskii Subject: Re: bug#18995: Error: Could not reserve dynamic heap area. In-reply-to: X-012-Sender: halo1@inter.net.il To: Alexander Shukaev Message-id: <83zjc0nvic.fsf@gnu.org> References: <834mu9r47v.fsf@gnu.org> <83y4rlpmsr.fsf@gnu.org> <83wq75plkm.fsf@gnu.org> <83vbmppj4a.fsf@gnu.org> <83r3xdpiex.fsf@gnu.org> <545E81BD.8070904@dancol.org> <83egtcpd3z.fsf@gnu.org> <87r3xcqqlp.fsf@igel.home> <83389spbdj.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18995 Cc: 18995@debbugs.gnu.org, dancol@dancol.org, schwab@linux-m68k.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 9 Nov 2014 17:53:25 +0100 > From: Alexander Shukaev > Cc: 18995@debbugs.gnu.org, dancol@dancol.org, schwab@linux-m68k.org > > Sheer luck: the first call to VirtualAlloc succeeds because it asks > for an amount that is much smaller than the 64-bit address space. > > > 32 GB is not that small. I have only 8 GB on my current car... (It's 256GB, not 32: the comment was wrong.) That call only _reserves_ the address space, it doesn't actually allocate anything. So the amount of memory actually available on your system is not important at that spot. What _is_ important is that in the 32-bit executable we are trying to reserve a significant portion of the 2GB address space of 32-bit programs, while in the 64-bit executable we reserve a very small portion of the address space. From unknown Fri Jun 20 07:14:16 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 08 Dec 2014 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator