[Bug 394] Y2038 time overflow/pre Epoch bug : java.lang.ExceptionInInitializerError on systems with uninitialized clock

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=394





------- Comment #7 from jon.vanalten at redhat.com  2010-06-22 14:49 -------
Whoops, I realize I mis-linked in comment #5.  The old bug I intended to
reference was:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4038100

(In reply to comment #5)
> (In reply to comment #4)
> > I don't believe this is really a JDK bug.
> 
> I think it still are a JDK bug

<sigh>, you're probably right.  More below.

> the exception happen
> before my own java programs main are executed and thus are uncatchable from the
> users java application. Please correct me if i am wrong here.

Absolutely correct.  This is static init of System class.

> You dont have to invent time travel in order to hit this bug, I have hit this
> bug several times during 2009-2010 by simply trying to boot up any java
> application on newly manufactured embedded hardware where the systemclock never
> have been set to a sane value.

I hadn't considered this, sorry.

> 
> Why should we not allow java applications to continue to run for people who
> manage to perform time travel jumps? 

I suppose if they manage this, we should accommodate them as much as possible. 
Their technology must be superior to, at least, my own.  :)

> It are perfectly possible that this bug makes any java driven time machine
> malfunction after the jump and prevents it to actually return back :)

Actually until 2038 overflow is solved, this will still be a possibility. 
Assuming their system clock changes to match their destination, if they travel
back in time or far enough forward to reach overflow, there are a number of
classes that will complain loudly.  A common general pattern of such a class
is:

old_time = System.currentTimeMillis();
// DO STUFF
new_time = System.currentTimeMillis();
if ((new_time - old_time) < 0) { throw Exception | System.exit() | other
undesirable action }

> 
> whats wrong with negative millis numbers? java doc only specify that
> currentTimeMillis() will return a long.

Indeed.  Funny, even though I looked at that when making previous comment, I
have always read "the difference, measured in milliseconds, between the current
time and midnight, January 1, 1970 UTC." as something like "time since January
1 1970".  My bad.

> 
> If initialization would be allowed to continue then i would actually be able to
> create a application written in java that could detect and update the clock.
> 

That would be nice.  Although, for reasons mentioned above, this may or may not
cause other issues.  Regardless, uncaught NPE at this point is not really
acceptable.

So from System.java:

"/**
     * The following two methods exist because in, out, and err must be
     * initialized to null.  The compiler, however, cannot be permitted to
     * inline access to them, since they are later set to more sensible values
     * by initializeSystemClass().
     */"
This comment precedes the method in which the previously mentioned
(currentTimeMillis() > 0) check is made.  So the call is mainly to prevent
inlining, rather than being an meaningful check of the system time.  Maybe we
can change the check to (currentTimeMillis() > Long.MIN_VALUE), this will at
least reduce the possibility of halting at this point to a single millisecond
clock value.  Or even use ">=", although I honestly am unsure whether compiler
will be smart enough to inline that.  I will try both.  Or if there is another
method that is safe to call at this stage to prevent the inlining, perhaps
someone has a suggestion for this.


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.