Bug 500077

Summary: jdk non-determenistic behavior
Product: [Fedora] Fedora Reporter: Need Real Name <mal>
Component: java-1.8.0-openjdkAssignee: Andrew Haley <aph>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 30CC: ahughes, dbhole, jerboaa, jvanek, lkundrak, msrb, mvala, omajid, patrickm, rruss
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-02 16:35:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
LOG(84572) test case
none
LOG(84572) test case with lower memory usage none

Description Need Real Name 2009-05-10 18:14:14 UTC
Because SUN does not respond to my  e-mail and bug reports, they seems already died I am posting this bug report here.

All jdk 1.6 have non-determenistic floating point.
The result depend on CPU type and memory preassure.

For example for the
v=(long) 84572.

the value of Math.log(v) may be equal to
11.34535852154476
or
11.345358521544759
yes, the difference is very minor, but the problem is  that what result will be produced
is unknown and non-determenistic.

This non-determenistic. behaviour
1) Violates FP spec.
2) Creates a problem comparing the results.

test case attached.
java t1
 LOG(84572)=11.34535852154476
 LOG(84572)=11.345358521544759
Exception in thread "main" java.lang.RuntimeException: Value mismatch: 11.345358521544759 and 11.34535852154476 arg=84572 try=0
	at t1.main(t1.java:81)

The problem exits on Latest SUN JDK
java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode)
Fedora 10 JDK
java -version
java version "1.6.0"
OpenJDK  Runtime Environment (build 1.6.0-b09)
OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)

and all other JDK 6 I tried.
The problem does not exist with gcj

gcj --main=t1 t1.java
./a.out 
 LOG(84572)=11.34535852154476
.... no exception after few hours of calculation.

Comment 1 Need Real Name 2009-05-10 18:15:23 UTC
Also note the program t1.java uses a lot of memory and may hang the computer.

Comment 2 Need Real Name 2009-05-10 18:16:44 UTC
Created attachment 343280 [details]
LOG(84572) test case

test case

Comment 3 Need Real Name 2009-05-10 18:33:48 UTC
Created attachment 343281 [details]
LOG(84572) test case with lower memory usage

javac -g t1.java
java  t1
 LOG(84572)=11.34535852154476
 LOG(84572)=11.345358521544759
Exception in thread "main" java.lang.RuntimeException: Value mismatch: 11.345358521544759 and 11.34535852154476 arg=84572 try=0
	at t1.main(t1.java:81)

Comment 4 Need Real Name 2009-05-10 18:37:44 UTC
The problem also exists on 
java -version
java version "1.6.0_0"
IcedTea6 1.4 (fedora-15.b14.fc10-x86_64) Runtime Environment (build 1.6.0_0-b14)
OpenJDK 64-Bit Server VM (build 14.0-b08, mixed mode)


java t1
 LOG(84572)=11.34535852154476
 LOG(84572)=11.345358521544759
Exception in thread "main" java.lang.RuntimeException: Value mismatch: 11.345358521544759 and 11.34535852154476 arg=84572 try=0
        at t1.main(t1.java:81)

Comment 5 Omair Majid 2009-05-11 21:05:27 UTC
I believe this is the upstream bug: http://bugs.sun.com/view_bug.do?bug_id=6539464

And this is the patch: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/819880572f09. Currently, it's only in OpenJDK 7, but a quick backport of the patch to IcedTea6 seems to work.

Comment 6 Need Real Name 2009-06-06 21:48:00 UTC
It is not fixed in hs16(b01), 7(b56) , as SUN claims in
http://bugs.sun.com/view_bug.do?bug_id=6539464

The problem also exists in 
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b59)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b03, mixed mode)

see the code t1.java from 
https://bugzilla.redhat.com/show_bug.cgi?id=500077

$java -server -Xmx6500000K t1
 LOG(84572)=11.345358521544759
 LOG(84572)=11.34535852154476
Exception in thread "main" java.lang.RuntimeException: Value mismatch: 11.34535852154476 and 11.345358521544759 arg=84572 try=21
	at t1.main(t1.java:81)

But in 1.7.0-ea-b59 it takes much longer (about 5-10 minutes, and memory usage should reach over 2.5 Gb) for the code from t1.java to fail with exception.

Comment 7 Need Real Name 2009-06-06 21:55:32 UTC
also notice the difference between
java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)

and jdk7 in what log is first, and what log is the second.

 java -server -Xmx6500000K t1
 LOG(84572)=11.34535852154476
 LOG(84572)=11.345358521544759
Exception in thread "main" java.lang.RuntimeException: Value mismatch: 11.345358521544759 and 11.34535852154476 arg=84572 try=0
	at t1.main(t1.java:81)

Comment 8 Bug Zapper 2009-11-18 11:55:59 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Need Real Name 2009-11-18 13:35:51 UTC
F11 same issue

Comment 10 Fedora Update System 2010-03-13 17:51:56 UTC
java-1.6.0-openjdk-1.6.0.0-33.b17.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-33.b17.fc11

Comment 11 Fedora Update System 2010-03-13 17:54:05 UTC
java-1.6.0-openjdk-1.6.0.0-36.b17.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-36.b17.fc12

Comment 12 Fedora Update System 2010-03-15 09:29:37 UTC
java-1.6.0-openjdk-1.6.0.0-35.b17.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-35.b17.fc13

Comment 13 Fedora Update System 2010-03-16 00:41:18 UTC
java-1.6.0-openjdk-1.6.0.0-33.b17.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2010-03-16 00:45:24 UTC
java-1.6.0-openjdk-1.6.0.0-36.b17.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Need Real Name 2010-03-17 18:55:32 UTC
same problem:

java -version
java version "1.6.0_17"
OpenJDK Runtime Environment (IcedTea6 1.7.1) (fedora-33.b17.fc11-x86_64)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
[mal@comp tmp]$ java  t1
 LOG(84572)=11.34535852154476
 LOG(84572)=11.345358521544759
Exception in thread "main" java.lang.RuntimeException: Value mismatch: 11.345358521544759 and 11.34535852154476 arg=84572 try=0
	at t1.main(t1.java:81)
[mal@comp tmp]$

Comment 16 Fedora Update System 2010-03-23 23:27:59 UTC
java-1.6.0-openjdk-1.6.0.0-35.b17.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Andrew John Hughes 2010-10-13 21:48:16 UTC
This should be fixed in the new RPM about to hit f13 (java-1.6.0-openjdk-1.6.0.0-43.1.8.2.fc13).  Please reopen if not.

Comment 18 Need Real Name 2019-02-16 23:31:08 UTC
There seems to be a regression with non--determenistic java behavior in

openjdk version "1.8.0_201"
OpenJDK Runtime Environment (build 1.8.0_201-b09)
OpenJDK 64-Bit Server VM (build 25.201-b09, mixed mode)

typical situation with a complex, but deterministic, calculations:

diff -u /tmp/q1  /tmp/q2
--- /tmp/q1     2019-02-16 15:13:21.681564015 -0500
+++ /tmp/q2     2019-02-16 15:13:23.546570608 -0500
@@ -58,7 +58,7 @@
 0.0025375270877487388,
 0.004908931898335285,
 0.027731275982055735,
-0.048625366378130516,
+0.04862536637813051,
 0.01735447552729801,
 5.696785978371326E-4,
 0.0026957826263760147,

It used to work OK

Comment 19 Need Real Name 2019-02-16 23:40:51 UTC
It to worked OK in 
 java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b13)
OpenJDK 64-Bit Server VM (build 25.191-b13, mixed mode)

I run the unit test multiple times - the results are identical. But in OpenJDK 64-Bit Server VM (build 25.201-b09, mixed mode) multiple runs create slightly different output.


This is really annoying bug, java behavior is non--deterministic, unit tests fail.

Comment 20 Ben Cotton 2019-02-19 17:11:28 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle.
Changing version to '30.

Comment 21 Andrew Haley 2020-03-02 16:35:36 UTC
I can't see anything here that I can work on. The original bug is fixed. If you still see something wrong, please open another bug with a proper test case.