United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6860491 WRAP_TIME_MILLIS incorrectly set
JDK-6860491 : WRAP_TIME_MILLIS incorrectly set

Details
Type:
Bug
Submit Date:
2009-07-14
Status:
Resolved
Updated Date:
2010-05-11
Project Name:
JDK
Resolved Date:
2009-08-24
Component:
client-libs
OS:
solaris_10
Sub-Component:
java.awt
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u11,6u13
Fixed Versions:
5.0u21 (b01)

Related Reports
Backport:
Backport:
Backport:
Backport:
Relates:

Sub Tasks

Description
Current source code from jdk 5u18:

public static final int MAX_VALUE = 0x7fffffff; j2se/src/share/classes/java/lang
/Integer.java, line 46

static final long WRAP_TIME_MILLIS = Integer.MAX_VALUE; j2se/src/solaris/classes
/sun/awt/X11/XToolkit.java, line 1410



WRAP_TIME_MILLIS is set to the maximum value of a signed 32 bit integer
((2^31) - 1), but it needs to be set to the maximum value of an *unsigned*
32 bit integer ((2^32) - 1). See the X11 specification for a description of
the X server timestamps. They are defined to be 32-bit unsigned integers
representing milliseconds and will wrap around every 49.7 days. The JRE code
is incorrectly setting the wrap time (WRAP_TIME_MILLIS) to 24.85 days
((2^31) - 1 milliseconds).

Need a bug and escalation filed against jdk 5.

See More for Additional info from customer.


To give you an idea as to what the problem is and the fix, I've pasted in below
the change I think needs to be made to the source code of sun.awt.X11.XToolkit.j
ava:
>>
>> static long reset_time_utc;
>>
>> ////////////// Modified Code ///////////////
>> // The following line of code has been replaced:
>> // static final long WRAP_TIME_MILLIS = Integer.MAX_VALUE;
>> //
>> // The problem is that Integer.MAX_VALUE is the max value for a SIGNED intege
r,
>> // but the X server uses an UNSIGNED integer for its timestamps, so
>> // WRAP_TIME_MILLIS should be set to 0x00000000FFFFFFFFL instead. Here is
>> // the replacement line of code:
>> static final long WRAP_TIME_MILLIS = 0x00000000FFFFFFFFL;
>> // With the old code, during the period of time when the X server timestamps
were
>> // between Integer.MAX_VALUE and 0x00000000FFFFFFFFL (24.85 days),
>> // getCurrentServerTime would get called every time nowMillisUTC_offset was
>> // called (which is a lot). In the period of time when the X server timestamp
s
>> // were between 0 and Integer.MAX_VALUE (also 24.85 days), the behavior was c
orrect and
>> // getCUrrentServerTime would be called only the first time nowMillisUTC_offs
et
>> // was called in a session. This caused the situation where this function beh
aved fine
>> // for 24.85 days and then behaved badly for next 24.85 days, then fine again
 for 24.85
>> // days, etc.
>> ////////////// End Modified Code ///////////
>>
>> static long nowMillisUTC_offset(long server_offset) {
>> // ported from awt_util.c
>> /*
>> * Because Time is of type 'unsigned long', it is possible that Time will
>> * never wrap when using 64-bit Xlib. However, if a 64-bit client
>> * connects to a 32-bit server, I suspect the values will still wrap. So
>> * we should not attempt to remove the wrap checking even if _LP64 is
>> * true.
>> */
>>
>> long current_time_utc = System.currentTimeMillis();
>> if (log.isLoggable(Level.FINER)) {
>> log.finer("reset_time=" + reset_time_utc + ", current_time=" + current_time_u
tc
>> + ", server_offset=" + server_offset + ", wrap_time=" + WRAP_TIME_MILLIS);
>> }
>>
>> if ((current_time_utc - reset_time_utc) > WRAP_TIME_MILLIS) {
>> reset_time_utc = System.currentTimeMillis() - getCurrentServerTime();
>> }
>>
>> if (log.isLoggable(Level.FINER)) {
>> log.finer("result = " + (reset_time_utc + server_offset));
>> }
>> return reset_time_utc + server_offset;
>> }
>>

                                    

Comments
EVALUATION

fix as suggested.
                                     
2009-07-23



Hardware and Software, Engineered to Work Together