From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18995: Error: Could not reserve dynamic heap area. Date: Sun, 09 Nov 2014 18:12:16 +0200 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1415549606 16432 80.91.229.3 (9 Nov 2014 16:13:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Nov 2014 16:13:26 +0000 (UTC) Cc: haroogan@gmail.com, 18995-done@debbugs.gnu.org To: Daniel Colascione Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 09 17:13:19 2014 Return-path: Envelope-to: geb-bug-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 1XnV78-0006em-E7 for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Nov 2014 17:13:18 +0100 Original-Received: from localhost ([::1]:39174 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnV77-00013J-Pr for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Nov 2014 11:13:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41672) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnV6z-00010G-1R for bug-gnu-emacs@gnu.org; Sun, 09 Nov 2014 11:13:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XnV6t-0001wi-5D for bug-gnu-emacs@gnu.org; Sun, 09 Nov 2014 11:13:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnV6t-0001wW-2t for bug-gnu-emacs@gnu.org; Sun, 09 Nov 2014 11:13:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XnV6s-0002Ad-U5 for bug-gnu-emacs@gnu.org; Sun, 09 Nov 2014 11:13:02 -0500 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Nov 2014 16:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 18995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Mail-Followup-To: 18995@debbugs.gnu.org, eliz@gnu.org, haroogan@gmail.com Original-Received: via spool by 18995-done@debbugs.gnu.org id=D18995.14155495578301 (code D ref 18995); Sun, 09 Nov 2014 16:13:02 +0000 Original-Received: (at 18995-done) by debbugs.gnu.org; 9 Nov 2014 16:12:37 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <545E81BD.8070904@dancol.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:95771 > 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!