GNU bug report logs - #18995
Error: Could not reserve dynamic heap area.

Previous Next

Package: emacs;

Reported by: Alexander Shukaev <haroogan <at> gmail.com>

Date: Sat, 8 Nov 2014 15:24:01 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Daniel Colascione <dancol <at> dancol.org>
To: 18995 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, haroogan <at> gmail.com
Subject: bug#18995: Error: Could not reserve dynamic heap area.
Date: Sun, 09 Nov 2014 16:40:17 +0000
[Message part 1 (text/plain, inline)]
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 <dancol <at> dancol.org>
>> CC: haroogan <at> 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?
> 
> 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 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".
>>
>> 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.
> 
> 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.


[signature.asc (application/pgp-signature, attachment)]

This bug report was last modified 10 years and 196 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.