bug#18995: Error: Could not reserve dynamic heap area.

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

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@dancol.org>
>> 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?
> 
> 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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]