JDK-8025644 : java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java fails with TestData$OfRef): failure java.lang.AssertionError: expected [true] but found [false]
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,8,8u20
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-09-30
  • Updated: 2015-02-02
  • Resolved: 2014-03-11
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.
JDK 7 JDK 8 JDK 9
7u80Fixed 8u20 b06Fixed 9Fixed
Description
test public void org.openjdk.tests.java.util.stream.ToArrayOpTest.testStatefulOpPermutations(java.lang.String,java.util.stream.TestData$OfRef): failure
java.lang.AssertionError: expected [true] but found [false]
	at org.testng.Assert.fail(Assert.java:89)
	at org.testng.Assert.failNotEquals(Assert.java:489)
	at org.testng.Assert.assertTrue(Assert.java:37)
	at org.testng.Assert.assertTrue(Assert.java:47)
	at org.openjdk.tests.java.util.stream.ToArrayOpTest.testStatefulOpPermutations(ToArrayOpTest.java:192)
	at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:491)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
	at org.testng.TestRunner.privateRun(TestRunner.java:767)
	at org.testng.TestRunner.run(TestRunner.java:617)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
	at org.testng.SuiteRunner.run(SuiteRunner.java:240)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:51)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:85)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1197)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1122)
	at org.testng.TestNG.run(TestNG.java:1030)
	at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:155)
	at com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:139)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:491)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:724)
Comments
Someone from the community could also backport this to 7u if they wanted it.
02-07-2014
Sustaining is handling backports to 7 and earlier. [~mcastegr], can you guys backport this one?
02-07-2014
This bug seems to happen in HS24, as well. Any interest in backporting this to 7u? The backport is trivial (and I've locally verified that it fixes the test cases of ours that fail).
02-07-2014
The problem is with the array store type check. Here is the normal scenario: In Parse::array_store_check() we speculatively assume the klass of the array (see the check and the UCT we emit there). If we pass the check the type of the array is exact and hence the type of klass the array element is exact. We pass that klass of the element as the superklass to gen_checkcast(). The maybe_cast_profiled_receiver() kicks in and tries to statically cast the speculative type of the object that we want to store into the array to the superklass, if it can do that (SSC_always_true) the only other thing we need to check is that the type of the object is indeed the type we expect (another check and UCT). If we cannot do the static cast, maybe_cast_profiled_receiver() returns null and we emit a full blown check. Now the bad scenario: We deopted too much in the array klass check we emitted in Parse::array_store_check(). So when we recompile we skip the opportunity to assert the exactness of the klass of the array (too_many_traps(Deoptimization::Reason_array_check) == true), and just load the element type klass from the inexact array klass. The element klass type would be j.l.Object and not exact (we cannot really know in this case until we load). We go into gen_checkcast() and into maybe_cast_profiled_receiver() assuming this element klass is the superklass. And we happily rely of the non-exact type to statically cast our speculative type of the stores object to j.l.Object. Which is wrong. The whole thing only works if the superklass is the true exact superklass. So, the fix is not to do the second part of the speculation if we don���t really know the exact type of the element, which is really a requirement for it all to work. Instead we should just emit the full check. Suggested fix: http://cr.openjdk.java.net/~iveresov/8025644/webrev.00/
31-01-2014
This was marked as resolved for some reason and hiding, but it seems to be failing. Taking a look at it...
28-01-2014
Possibly some change in hotspot is causing this
03-10-2013
Also i see in the jtreg output hotspot versions such as: java version "1.8.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b108) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b52-internal-201309242310.vkozlov.8022585-fastdebug, mixed mode) and: java version "1.8.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b109) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b52-internal-201310010635.jrose.8025260-fastdebug, mixed mode) Are you using experimental builds of hotspot? If so can you please run/compare tests against JDK 8 master repository to obtain a baseline of known failures compared to failures with different builds of hotspot? If this test passes in builds of the JDK 8 master then it is highly unlikely to be a bug in the stream API.
03-10-2013
Why is the VM option -XX:+UnlockExperimentalVMOptions being used? There is still something odd i see other tests failing on some platforms: java/util/stream/boottest/java/util/stream/StreamOpFlagsTest.java java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java which makes be very suspicious that something is not quite right with the setup.
03-10-2013
The failure is occurring when attempting to use the wrong array type for the array generator: Exception caught = null; try { exerciseTerminalOps(data, f, s -> s.toArray(String[]::new)); } catch (Exception e) { caught = e; } assertTrue(caught != null); assertEquals(caught.getClass(), ArrayStoreException.class); An ArrayStoreException is expected and no exception is thrown i.e String != Integer This is very suspicious. Nothing has recently changed in this area, it's been stable for quite a while, when i run locally on my Mac all tests pass, and there is nothing platform specific about this test. Do you have any more data/history on this test? does it fail on other machines? i must admit i find aurora very confusing when attempting to look at history plus there is a lot of noise with compilation failures.
30-09-2013