RFR JDK-8130914: java/util/zip/TestExtraTime.java fails with "java.lang.RuntimeException: setTime should make getLastModifiedTime return the specified instant: 3078282244456 got: 3078282244455"
Hi, Please help review the change for JDK-8130914. issue: https://bugs.openjdk.java.net/browse/JDK-8130914 webrev: http://cr.openjdk.java.net/~sherman/8130914/ This is a "regression" triggered by https://bugs.openjdk.java.net/browse/JDK-8130914 http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/ In which the change is to utilize a high 32-bit of the time value to store < 2000 ms time piece. It appears the offending timestamp (year 2067...) triggers the 32-bit "overflow" when converting java time to a 32-bit dos time. Thanks, -Sherman
Code change looks OK to me, but perhaps there should be an explicit long conversion somewhere around the getYear() part ('d.getYear() - 1980 << 25L') of the expressions to deal properly with even larger values? Are there added tests missing from the updated TestExtraTime? I guess this is an intermittent issue, but it looks odd to update the test without adding some explicit test that provoke this issue. /Claes Xueming Shen <xueming.shen@oracle.com> skrev: (15 juli 2015 21:10:39 CEST)
Hi,
Please help review the change for JDK-8130914.
issue: https://bugs.openjdk.java.net/browse/JDK-8130914 webrev: http://cr.openjdk.java.net/~sherman/8130914/
This is a "regression" triggered by https://bugs.openjdk.java.net/browse/JDK-8130914 http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
In which the change is to utilize a high 32-bit of the time value to store < 2000 ms time piece. It appears the offending timestamp (year 2067...) triggers the 32-bit "overflow" when converting java time to a 32-bit dos time.
Thanks, -Sherman
On 07/15/2015 03:33 PM, Claes Redestad wrote:
Code change looks OK to me, but perhaps there should be an explicit long conversion somewhere around the getYear() part ('d.getYear() - 1980 << 25L') of the expressions to deal properly with even larger values?
The spec of the dos time has the up limit, it should not beyond 32-bit. It was not a problem when anything number overflows into up 32-bit before we tried to utilize the up bits for the < 2000ms bits.
Are there added tests missing from the updated TestExtraTime? I guess this is an intermittent issue, but it looks odd to update the test without adding some explicit test that provoke this issue.
It appears this existing test can easily catch the bug, so I just add the bugid to indicate that this regression test can be used for that particular bug. thanks, -sherman
/Claes
Xueming Shen <xueming.shen@oracle.com> skrev: (15 juli 2015 21:10:39 CEST)
Hi,
Please help review the change for JDK-8130914.
issue:https://bugs.openjdk.java.net/browse/JDK-8130914 webrev:http://cr.openjdk.java.net/~sherman/8130914 <http://cr.openjdk.java.net/%7Esherman/8130914>/
This is a "regression" triggered by https://bugs.openjdk.java.net/browse/JDK-8130914 http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6 <http://cr.openjdk.java.net/%7Eredestad/jdk9/8073497/webrev.6>/
In which the change is to utilize a high 32-bit of the time value to store < 2000 ms time piece. It appears the offending timestamp (year 2067...) triggers the 32-bit "overflow" when converting java time to a 32-bit dos time.
Thanks, -Sherman
Hi Sherman, On 07/15/2015 09:10 PM, Xueming Shen wrote:
Hi,
Please help review the change for JDK-8130914.
issue: https://bugs.openjdk.java.net/browse/JDK-8130914 webrev: http://cr.openjdk.java.net/~sherman/8130914/
This is a "regression" triggered by https://bugs.openjdk.java.net/browse/JDK-8130914 http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
And-ing the result with a 32 bit mask (2^32 - 1) does make sure that high 32 bits are not touched by year encoding. As I understand, this starts to be a problem with year 2044 and beyond when (year - 1980) << 25 becomes a negative number. Expanding it to long sets the high 32 bits too. If we treat the lower 32 bits as unsigned, we accommodate for years up to and including 2107. At 2108, the overflow happens and decoding the year back gives 1980 instead of 2108. So I wonder: - will there be a DOS compatible ZIP format after 2108 ? - will there be Java after 2108 ? - depending on the above answers, should there be a DOSTIME_AFTER_2107 in addition to DOSTIME_BEFORE_1980 to which the date is clamped? Regards, Peter
In which the change is to utilize a high 32-bit of the time value to store < 2000 ms time piece. It appears the offending timestamp (year 2067...) triggers the 32-bit "overflow" when converting java time to a 32-bit dos time.
Thanks, -Sherman
On 7/17/15 1:04 AM, Peter Levart wrote:
Hi Sherman,
On 07/15/2015 09:10 PM, Xueming Shen wrote:
Hi,
Please help review the change for JDK-8130914.
issue: https://bugs.openjdk.java.net/browse/JDK-8130914 webrev: http://cr.openjdk.java.net/~sherman/8130914/
This is a "regression" triggered by https://bugs.openjdk.java.net/browse/JDK-8130914 http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
And-ing the result with a 32 bit mask (2^32 - 1) does make sure that high 32 bits are not touched by year encoding. As I understand, this starts to be a problem with year 2044 and beyond when (year - 1980) << 25 becomes a negative number. Expanding it to long sets the high 32 bits too. If we treat the lower 32 bits as unsigned, we accommodate for years up to and including 2107. At 2108, the overflow happens and decoding the year back gives 1980 instead of 2108. So I wonder: - will there be a DOS compatible ZIP format after 2108 ? - will there be Java after 2108 ?
Yes, dos timestamp has a 2107 ceiling, given it's 32-bit nature, like the unix time has a 2038 ceiling if the long stays as 32-bit.
- depending on the above answers, should there be a DOSTIME_AFTER_2107 in addition to DOSTIME_BEFORE_1980 to which the date is clamped?
If ZIP is still being used on 2107, "we" have a problem. -Sherman
Regards, Peter
In which the change is to utilize a high 32-bit of the time value to store < 2000 ms time piece. It appears the offending timestamp (year 2067...) triggers the 32-bit "overflow" when converting java time to a 32-bit dos time.
Thanks, -Sherman
On 7/17/15 8:45 AM, Xueming Shen wrote:
On 7/17/15 1:04 AM, Peter Levart wrote:
Hi Sherman,
On 07/15/2015 09:10 PM, Xueming Shen wrote:
Hi,
Please help review the change for JDK-8130914.
issue: https://bugs.openjdk.java.net/browse/JDK-8130914 webrev: http://cr.openjdk.java.net/~sherman/8130914/
This is a "regression" triggered by https://bugs.openjdk.java.net/browse/JDK-8130914 http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
And-ing the result with a 32 bit mask (2^32 - 1) does make sure that high 32 bits are not touched by year encoding. As I understand, this starts to be a problem with year 2044 and beyond when (year - 1980) << 25 becomes a negative number. Expanding it to long sets the high 32 bits too. If we treat the lower 32 bits as unsigned, we accommodate for years up to and including 2107. At 2108, the overflow happens and decoding the year back gives 1980 instead of 2108. So I wonder: - will there be a DOS compatible ZIP format after 2108 ? - will there be Java after 2108 ?
Yes, dos timestamp has a 2107 ceiling, given it's 32-bit nature, like the unix time has a 2038 ceiling if the long stays as 32-bit.
- depending on the above answers, should there be a DOSTIME_AFTER_2107 in addition to DOSTIME_BEFORE_1980 to which the date is clamped?
btw, we do have a ZipEntry.UPPER_DOSTIME_BOUND to help save a timestamp into the extra field, if necessary. -sherman
Hi Sherman, Sorry for the delay, that looks fine. If zip is still around that far in the future, everyone will have the same problem. Roger On 7/17/2015 12:12 PM, Xueming Shen wrote:
On 7/17/15 8:45 AM, Xueming Shen wrote:
On 7/17/15 1:04 AM, Peter Levart wrote:
Hi Sherman,
On 07/15/2015 09:10 PM, Xueming Shen wrote:
Hi,
Please help review the change for JDK-8130914.
issue: https://bugs.openjdk.java.net/browse/JDK-8130914 webrev: http://cr.openjdk.java.net/~sherman/8130914/
This is a "regression" triggered by https://bugs.openjdk.java.net/browse/JDK-8130914 http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
And-ing the result with a 32 bit mask (2^32 - 1) does make sure that high 32 bits are not touched by year encoding. As I understand, this starts to be a problem with year 2044 and beyond when (year - 1980) << 25 becomes a negative number. Expanding it to long sets the high 32 bits too. If we treat the lower 32 bits as unsigned, we accommodate for years up to and including 2107. At 2108, the overflow happens and decoding the year back gives 1980 instead of 2108. So I wonder: - will there be a DOS compatible ZIP format after 2108 ? - will there be Java after 2108 ?
Yes, dos timestamp has a 2107 ceiling, given it's 32-bit nature, like the unix time has a 2038 ceiling if the long stays as 32-bit.
- depending on the above answers, should there be a DOSTIME_AFTER_2107 in addition to DOSTIME_BEFORE_1980 to which the date is clamped?
btw, we do have a ZipEntry.UPPER_DOSTIME_BOUND to help save a timestamp into the extra field, if necessary.
-sherman
participants (4)
-
Claes Redestad
-
Peter Levart
-
Roger Riggs
-
Xueming Shen