JDK-8200701 : jdk/jshell/ExceptionsTest.java fails on Windows, after JDK-8198801
  • Type: Bug
  • Component: tools
  • Sub-Component: jshell
  • Affected Version: 11
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-04-04
  • Updated: 2020-05-06
  • Resolved: 2019-06-18
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 11 JDK 13 JDK 14
11.0.8Fixed 13 b26Fixed 14Fixed
Related Reports
Relates :  
JDK-8225208 - Re-Problem list jdk/jshell/ExceptionsTest.java fails on windows
Relates :  
JDK-8080353 - JShell: Better error message on attempting to add default method
Relates :  
JDK-8198801 - JShell: user exception chained cause not retained
Relates :  
JDK-8212167 - JShell : Stack trace of exception has wrong line number
Relates :  
JDK-8159740 - JShell: corralled declarations do not have correct source to wrapper mapping
Relates :  
JDK-8200703 - Problem list jdk/jshell/ExceptionsTest.java fails on windows
Description
jdk/jshell/ExceptionsTest.java fails at windows-x64, after JDK-8198801, reproducible.

test ExceptionsTest.throwChainedUnresolved(): failure
java.lang.AssertionError: Given ""
Stack trace:
jdk.jshell.UnresolvedReferenceException: Attempt to use definition snippet with unresolved references in MethodSnippet:n/()void-void n() throws Exception { try { p(); } catch (Exception ex) { throw new java.io.IOException("error_message2", ex); }}
	at .n(#2:3)
	at .m(#3:2)
	at .(#4:1)

 : line numbers expected [1] but found [3]
	at org.testng.Assert.fail(Assert.java:94)
	at org.testng.Assert.failNotEquals(Assert.java:496)
	at org.testng.Assert.assertEquals(Assert.java:125)
	at org.testng.Assert.assertEquals(Assert.java:372)
	at ExceptionsTest.assertStackTrace(ExceptionsTest.java:335)
	at ExceptionsTest.assertStackMatch(ExceptionsTest.java:298)
	at ExceptionsTest.assertAnyExceptionMatch(ExceptionsTest.java:314)
	at ExceptionsTest.assertExceptionMatch(ExceptionsTest.java:289)
	at ExceptionsTest.assertExceptionMatch(ExceptionsTest.java:270)
	at ExceptionsTest.throwChainedUnresolved(ExceptionsTest.java:126)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
	at org.testng.TestRunner.privateRun(TestRunner.java:773)
	at org.testng.TestRunner.run(TestRunner.java:623)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
	at org.testng.TestNG.run(TestNG.java:1018)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:229)
	at java.base/java.lang.Thread.run(Thread.java:831)
Comments
Verified by the test passing -- set noreg-self
13-08-2019
Ah! So all that changed was that we unintentionally started running the test again. At least it no longer seems intermittent so actually tracking down the problem should be easier. :)
03-06-2019
Alas, not coincidence. See JDK-8225208
03-06-2019
Must be coincidence then, but this test started failing regularly from CI jdk-13-1200 in which the only new changeset was for JDK-8080353. Given this is intermittent there must be some kind of race that triggers the issue, so the recent changes likely altered the race conditions.
03-06-2019
The failed method -- public void throwChainedUnresolved() { String message1 = "error_message1"; String message2 = "error_message2"; Snippet s1 = methodKey(assertEval("void p() throws Exception { ((String) null).toString(); }")); Snippet s2 = methodKey(assertEval("void n() throws Exception { try { p(); } catch (Exception ex) { throw new java.io.IOException(\"" + message2 + "\", ex); }}")); Snippet s3 = methodKey(assertEval("void m() {\n" + "try { n(); }\n" + "catch (Exception ex) {\n" + " throw new RuntimeException(\"" + message1 + "\", ex);\n" + "}}")); getState().drop(s1); SnippetEvent cr4 = assertEvalException("m();"); assertExceptionMatch(cr4, new ExceptionInfo(RuntimeException.class, message1, new UnresolvedExceptionInfo(s2, newStackTraceElement("", "n", s2, 1), newStackTraceElement("", "m", s3, 2), newStackTraceElement("", "", cr4.snippet(), 1)), newStackTraceElement("", "m", s3, 4), newStackTraceElement("", "", cr4.snippet(), 1))); }
03-06-2019
JDK-8080353 has nothing in common with this. Either it just tweaked a randomness, or some other change (compiler? Runtime exception handling?) went in at that time that did change it.
03-06-2019
This is failing in every tier 1 run. Is the fix nearby or do we problemlist the test?
03-06-2019
Something must have changed to make this fail every run. Looks like it started when JDK-8080353 was pushed.
03-06-2019
JDK-8080353?
03-06-2019
intermittent label was not added by me, and I think it should be removed. I just tried on Mach 5 with latest code, the failure is still reproducible.
20-05-2019
Amy, This report and the comment above say it is reproducible. But it is labelled intermittent. Please clarify. I ran it with ProblemList removed under Mach5, and it passed. Does that mean you would not see it either?
19-05-2019
Test is problem listed on Windows (JDK-8200703) now.
04-04-2018