Request for sponsor: 4421494 infinite loop while parsing double literal

[Dmitry Nadezhin]

http://bugs.sun.com/view_bug.do?bug_id=4421494
https://bugs.openjdk.java.net/show_bug.cgi?id=100119

Summary: This old bug report says that Double.parseDouble(s) hangs for decimal strings
in range (Double.MIN_NORMAL-0.5*Double.MIN_VALUE,Double.MIN), and returns
incorrect result for decimal string Double.MIN_NORMAL-0.5*Double.MIN_VALUE.

This is because current code in FloatingDecimal.doubleValue() incorrectly
defines the condition when nextDown(dValue) - dValue == -0.5*ulp(dValue). The
current code considers that these are all numbers 2^n which are represented as
normal doubles, and nexDown(dValue) - dValue == -1.0*ulp(dValue) for other
doubles (subnormal or not 2-powers).
However, this is not correct for dValue == Double.MIN_VALUE, because
nextDown(Double.MIN_NORMAL) - Double.MIN_NORMAL == -1.0*ulp(Double.MIN_NORMAL).

The suggested change
-                    if ( (bigIntNBits == 1) && (bigIntExp > -expBias) ){
+                    if ( (bigIntNBits == 1) && (bigIntExp > -expBias+1) ){
redefines the condition so that dValue == Double.MIN_NORMAL doesn't satisfy it.

 -Dima

[joe.darcy]

Dmitry Nadezhin wrote:

> http://bugs.sun.com/view_bug.do?bug_id=4421494
> https://bugs.openjdk.java.net/show_bug.cgi?id=100119
>
> Summary: This old bug report says that Double.parseDouble(s) hangs for
> decimal strings
> in range (Double.MIN_NORMAL-0.5*Double.MIN_VALUE,Double.MIN), and returns
> incorrect result for decimal string
> Double.MIN_NORMAL-0.5*Double.MIN_VALUE.
>
> This is because current code in FloatingDecimal.doubleValue() incorrectly
> defines the condition when nextDown(dValue) - dValue ==
> -0.5*ulp(dValue). The
> current code considers that these are all numbers 2^n which are
> represented as
> normal doubles, and nexDown(dValue) - dValue == -1.0*ulp(dValue) for
> other
> doubles (subnormal or not 2-powers).
> However, this is not correct for dValue == Double.MIN_VALUE, because
> nextDown(Double.MIN_NORMAL) - Double.MIN_NORMAL ==
> -1.0*ulp(Double.MIN_NORMAL).
>
> The suggested change
> -                    if ( (bigIntNBits == 1) && (bigIntExp > -expBias) ){
> +                    if ( (bigIntNBits == 1) && (bigIntExp >
> -expBias+1) ){
> redefines the condition so that dValue == Double.MIN_NORMAL doesn't
> satisfy it.
>
> -Dima

Hello.

Thank you for the proposed fix; that certainly sounds like a plausible
cause of the problem.

I'm a bit swamped now, but I'll try to look at verifying the fix and
sponsoring getting it back into the JDK within the next few weeks.

-Joe

[Dmitry Nadezhin]

Hello Joe,

Thank you for the sponsorship of the bug 4421494.

I can also prepare a fix for another related bug 4396272
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4396272

The bug 4396272 is blinking because it occurs only when HotSpot chooses
double value set and it doesn't occur
with double-extended-exponent value set.
The suggested fix will be in FloatingDecimal too, though in other line.

What is more convenient to you
a) if I combine both fixes of 4421494 and 4396272 in a single changeset now;
b) if I postpone submitting of the fix 4396272 until 4421494 is in the JDK
?

  -Dima

> Dmitry Nadezhin wrote:
>> http://bugs.sun.com/view_bug.do?bug_id=4421494
>> https://bugs.openjdk.java.net/show_bug.cgi?id=100119
>>
>> Summary: This old bug report says that Double.parseDouble(s) hangs
>> for decimal strings
>> in range (Double.MIN_NORMAL-0.5*Double.MIN_VALUE,Double.MIN), and
>> returns
>> incorrect result for decimal string
>> Double.MIN_NORMAL-0.5*Double.MIN_VALUE.
>>
>> This is because current code in FloatingDecimal.doubleValue()
>> incorrectly
>> defines the condition when nextDown(dValue) - dValue ==
>> -0.5*ulp(dValue). The
>> current code considers that these are all numbers 2^n which are
>> represented as
>> normal doubles, and nexDown(dValue) - dValue == -1.0*ulp(dValue) for
>> other
>> doubles (subnormal or not 2-powers).
>> However, this is not correct for dValue == Double.MIN_VALUE, because
>> nextDown(Double.MIN_NORMAL) - Double.MIN_NORMAL ==
>> -1.0*ulp(Double.MIN_NORMAL).
>>
>> The suggested change
>> -                    if ( (bigIntNBits == 1) && (bigIntExp >
>> -expBias) ){
>> +                    if ( (bigIntNBits == 1) && (bigIntExp >
>> -expBias+1) ){
>> redefines the condition so that dValue == Double.MIN_NORMAL doesn't
>> satisfy it.
>>
>> -Dima
>
> Hello.
>
> Thank you for the proposed fix; that certainly sounds like a plausible
> cause of the problem.
>
> I'm a bit swamped now, but I'll try to look at verifying the fix and
> sponsoring getting it back into the JDK within the next few weeks.
>
> -Joe

[joe.darcy]

Dmitry Nadezhin wrote:

> Hello Joe,
>
> Thank you for the sponsorship of the bug 4421494.
>
> I can also prepare a fix for another related bug 4396272
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4396272
>
> The bug 4396272 is blinking because it occurs only when HotSpot
> chooses double value set and it doesn't occur
> with double-extended-exponent value set.
> The suggested fix will be in FloatingDecimal too, though in other line.
>
> What is more convenient to you
> a) if I combine both fixes of 4421494 and 4396272 in a single
> changeset now;
> b) if I postpone submitting of the fix 4396272 until 4421494 is in the
> JDK
> ?

If the first fix is just a one-liner, combining the two fixes is easier
overall.

Cheers,

-Joe

>  -Dima
>> Dmitry Nadezhin wrote:
>>> http://bugs.sun.com/view_bug.do?bug_id=4421494
>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100119
>>>
>>> Summary: This old bug report says that Double.parseDouble(s) hangs
>>> for decimal strings
>>> in range (Double.MIN_NORMAL-0.5*Double.MIN_VALUE,Double.MIN), and
>>> returns
>>> incorrect result for decimal string
>>> Double.MIN_NORMAL-0.5*Double.MIN_VALUE.
>>>
>>> This is because current code in FloatingDecimal.doubleValue()
>>> incorrectly
>>> defines the condition when nextDown(dValue) - dValue ==
>>> -0.5*ulp(dValue). The
>>> current code considers that these are all numbers 2^n which are
>>> represented as
>>> normal doubles, and nexDown(dValue) - dValue == -1.0*ulp(dValue) for
>>> other
>>> doubles (subnormal or not 2-powers).
>>> However, this is not correct for dValue == Double.MIN_VALUE, because
>>> nextDown(Double.MIN_NORMAL) - Double.MIN_NORMAL ==
>>> -1.0*ulp(Double.MIN_NORMAL).
>>>
>>> The suggested change
>>> -                    if ( (bigIntNBits == 1) && (bigIntExp >
>>> -expBias) ){
>>> +                    if ( (bigIntNBits == 1) && (bigIntExp >
>>> -expBias+1) ){
>>> redefines the condition so that dValue == Double.MIN_NORMAL doesn't
>>> satisfy it.
>>>
>>> -Dima
>>
>> Hello.
>>
>> Thank you for the proposed fix; that certainly sounds like a
>> plausible cause of the problem.
>>
>> I'm a bit swamped now, but I'll try to look at verifying the fix and
>> sponsoring getting it back into the JDK within the next few weeks.
>>
>> -Joe
>

[Dmitry Nadezhin]

I put a combined changeset fixing bugs 4421494 and 4396272
as comment #2 and comment #3 to OpenJDK bugzilla report:
https://bugs.openjdk.java.net/show_bug.cgi?id=100119

  -Dima

Joseph D. Darcy wrote:

> Dmitry Nadezhin wrote:
>> Hello Joe,
>>
>> Thank you for the sponsorship of the bug 4421494.
>>
>> I can also prepare a fix for another related bug 4396272
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4396272
>>
>> The bug 4396272 is blinking because it occurs only when HotSpot
>> chooses double value set and it doesn't occur
>> with double-extended-exponent value set.
>> The suggested fix will be in FloatingDecimal too, though in other line.
>>
>> What is more convenient to you
>> a) if I combine both fixes of 4421494 and 4396272 in a single
>> changeset now;
>> b) if I postpone submitting of the fix 4396272 until 4421494 is in
>> the JDK
>> ?
>
> If the first fix is just a one-liner, combining the two fixes is
> easier overall.
>
> Cheers,
>
> -Joe