JDK-6860491 : WRAP_TIME_MILLIS incorrectly set
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0u11,6u13
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2009-07-14
  • Updated: 2010-05-11
  • Resolved: 2009-08-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7
5.0u21 b01Fixed 6u16-revFixed 7Fixed
Related Reports
Relates :  
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.
23-07-2009