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

[bugzilla-daemon at icedtea.classpath.org]

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





------- Comment #14 from xerxes at zafena.se  2010-06-28 10:00 -------
(In reply to comment #13)
> > (In reply to comment #10)
> >> The Y2038 bug is an issue with 32-bit systems only as time_t = pointer size. 
> >> So it affects x86 and arm, but not x86_64 where time_t will be 64-bit.
> > 
> > This bug can still hit on both 64bit and 32bit systems since time_t are
> > *signed*.
> > 
> > when time_t < 0 then it refers to pre Epoch time on both 32bit and 64bit
> > systems 
> 
> This doesn't make any sense.  currentTimeMillis() returns the current
> time in milliseconds.  The current time is not before 1970, and never
> will be.
> 

the sign bit can get in several ways.

1.
On newly manufactured hardware it are a random chance that the sign bit are set
and the hardware will fail to launch java if it are.
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. see comment #0

2.
system bootup/resume from suspend after a clock battery failure.
this can happen on any system with a clock battery that will eventually fail
over time.

3.
systems without a clock battery.

4. 
being trapped in the past by a java-timemachine bootup failure after jumping
back to pre 1970 time. please dont try java-timemachine jumps at home without
fixing this bug first.

5.
fluke, emp wave, etc etc, that flips the bit.

All of these errors above can of course get corrected in software...
but not in software written in Java due to this JVM bug!


> > John wrote:
> 
> >> Any checks that are failing simply because currentTimeMillis() is
> >> negative are bugs in themselves IMO (unless they really mean to
> >> check that the system clock is later than 1970), and should be
> >> fixed separately if found.
> > 
> > I cant agree more, and this bug are one of these cases when Java fails to
> > launch because currentTimeMillis() returns a negative number.
> 
> If currentTimeMillis() returns a negative number (on a 64-bit system), the
> system is not Java compatible.
> 

Why are it not Java compatible if it returns a negative number?
Java doc only states:
"Returns:
    the difference, measured in milliseconds, between the current time and
midnight, January 1, 1970 UTC."
http://java.sun.com/javase/6/docs/api/java/lang/System.html#currentTimeMillis%28%29


-- 
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.