harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Deakin (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-6370) [classlib][luni] GregorianCalendar edge-case can result in infinite loop
Date Thu, 05 Nov 2009 16:15:32 GMT
[classlib][luni] GregorianCalendar edge-case can result in infinite loop
------------------------------------------------------------------------

                 Key: HARMONY-6370
                 URL: https://issues.apache.org/jira/browse/HARMONY-6370
             Project: Harmony
          Issue Type: Bug
          Components: Classlib
            Reporter: Oliver Deakin


Running the following test:

import java.util.*;
class Test {
    public static void main(String[] args) {
        System.out.println("Starting Test...");
        GregorianCalendar gcalendar = new GregorianCalendar();
        gcalendar.setGregorianChange(new Date(Long.MIN_VALUE));
        gcalendar.setTimeInMillis(Long.MIN_VALUE);
        System.out.println("Test Complete");
    }
}

never returns from the setTimeInMillis() call. 

Calling setGregorianChange() with Long.MIN_VALUE is perfectly reasonable - it means you want
to use a purely Gregorian calendar and is mentioned in the spec. Calling setTimeInMillis()
with any value from Long.MIN_VALUE to approximately Long.MIN_VALUE+189485000000000L will cause
an infinite loop to occur, so it is quite a broad range of values, albeit values that may
never be used as they are so far in the past.

Debugging in the GregorianCalendar code, I have found that the setGregorianCalendar(Long.MIN_VALUE)
sets the change year from Julian to Gregorian calendars to be -292269054. However, once this
value is set, calling setTimeInMillis(Long.MIN_VALUE) actually tries to create a calendar
with a year slightly lower than this boundary value (because of the Gregorian leap year adjustments)!
The result is that we oscillate either side of the boundary value (-292269054) infinitely
as we switch from calculating the date in Gregorian to Julian calendars and back.

Although this is a corner case, the RI can complete this test successfully so I think it is
worth logging. I'm not sure what the best fix is. The simplest fix would probably be to check
in setGregorianChange() if the Date being passed in is the earliest date possible, and if
so just fixup the Gregorian change year to be Integer.MIN_VALUE instead of using the year
from the specified Date. This will ensure that all dates set with that calendar will be calculated
entirely in the Gregorian calendar (as described in the spec) and with this change I can no
longer recreate the infinite loop.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message