JDK-8171483 : Revisit com/sun/jdi/JdbMethodExitTest.sh
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: hs17,hs24,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2016-12-20
  • Updated: 2018-05-19
  • Resolved: 2018-05-19
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 12
12Resolved
Related Reports
Duplicate :  
JDK-8203393 - com/sun/jdi/JdbMethodExitTest.sh and JdbExprTest.sh fail due to timeout
Relates :  
JDK-8174241 - ProblemList update for TestWsImport, JdbMethodExitTest and jimage tests
Relates :  
JDK-8203393 - com/sun/jdi/JdbMethodExitTest.sh and JdbExprTest.sh fail due to timeout
Relates :  
JDK-8179318 - rewrite serviceability shell tests to java version
Relates :  
JDK-8185803 - JdbExprTest.sh fails in JDK10-hs nightly due to "Name unknown: java.lang.Long.MAX_VALUE "
Relates :  
JDK-6902121 - intermittent JdbMethodExitTest timeout
Description
com/sun/jdi/JdbMethodExitTest.sh                                6902121 generic-all

This test is in ProblemList.txt while the related bug JDK-6902121 has been closed.

Test needs to be revisited.
Please evaluate and remove test from ProblemList if issue does not exist anymore.
Comments
This CR has become too cluttered due to discussing multiple issues. I created JDK-8203393 to address the timeout issue we are seeing on solaris-sparc, and as mentioned in the previous comment, JDK-8203391 was created to address the URL[] failure seen on all platforms. Once the problem list is updated to reference JDK-8203393, I'll close this CR as a dup of JDK-8203393.
18-05-2018
Looks like this issue is the same as: JDK-8198808 - jdi tests failing after JDK-8198484 However, all this CR did is problemlist the failing tests, and this particular test was not run so the problem was not detected. The following was created to address the issue: JDK-8198803 - URLClassLoader does not specify behavior when URL array contains null That resulted in a spec clarification (the NPE is correct behavior) and a subtask to fix the jdi tests: JDK-8198933 - Update JDI tests to pass valid URL[] I'll create another subtask of that CR (JDK-8203391) to address fixing this test.
18-05-2018
In all likelihood, this change introduced the bug: JDK-8198484 - URLClassPath should use an ArrayDeque instead of a Stack I'm not sure yet if the test is actually at fault or if the modified URLClassPath implementation is.
18-05-2018
When I run the test class stand alone, and don't even bother with any of the debug command line options, I get: bash-4.1$ /local/ws/jdk/jdk1/build/linux-x64-debug/images/jdk/bin/java -classpath /local/ws/jdk/jdk1/build/linux-x64-debug/test-support/jtreg_open_test_jdk_com_sun_jdi_JdbMethodExitTest_sh/classes/0/com/sun/jdi/JdbMethodExitTest.d/aa16561 JdbMethodExitTest Exception in thread "main" java.lang.ExceptionInInitializerError Caused by: java.lang.NullPointerException at java.base/java.util.ArrayDeque.addLast(ArrayDeque.java:304) at java.base/java.util.ArrayDeque.add(ArrayDeque.java:495) at java.base/jdk.internal.loader.URLClassPath.<init>(URLClassPath.java:145) at java.base/jdk.internal.loader.URLClassPath.<init>(URLClassPath.java:162) at java.base/java.net.URLClassLoader.<init>(URLClassLoader.java:165) at JdbMethodExitTest.<init>(JdbMethodExitTest.java:27) at JdbMethodExitTest.<clinit>(JdbMethodExitTest.java:35) The line of test code is: { try { urls[0] = new URL("hi there"); } catch (java.net.MalformedURLException ee) { } classLoaderValue = new URLClassLoader(urls); <==== here } I'm not sure what behaviour is expected here. Clearly the URL is malformed so urls[0] should end up being NULL. Seems like this would always have generated an NPE, but from what I can, this NPE is new behavior. Not sure if it was intentional or not.
18-05-2018
Less than 3 months this test only had occasional failures on solaris-sparc. Now it fails with every run on every platform. When it passed I saw: ------------------------------------- Initializing jdb ... > VM Started: No frames on the current call stack main[1] Deferring breakpoint JdbMethodExitTest:84. It will be set after the class is loaded. main[1] > Set deferred breakpoint JdbMethodExitTest:84 threadid=1 Breakpoint hit: "thread=main", JdbMethodExitTest.bkpt(), line=84 bci=0 84 int i = 0; //@1 breakpoint ------------------------------------- And when it now fails: ------------------------------------- Initializing jdb ... VM Started: > No frames on the current call stack main[1] Deferring breakpoint JdbMethodExitTest:84. It will be set after the class is loaded. main[1] > Set deferred breakpoint JdbMethodExitTest:84 Exception occurred: java.lang.NullPointerException (uncaught)"thread=main", java.util.ArrayDeque.addLast(), line=304 bci=11 ------------------------------------- So there's an NPE before we even hit the breakpoint.
18-05-2018
Targeting this issue to 12. I agree, this issue will be resolved after conversion. But it is not clear if we will have time to sort this out in 11.
06-04-2018
This test is being converted to java as part of BKLG-805. This should resolve the waitForFinish() issue. Once a JDK bug is filed for the conversion, we can close this one as a dup.
29-03-2018
Looks like the waitForFinish output comes from ShellScaffold.sh, and it is different for Solaris. The Solaris logic is much more complicated than linux, which just has to do a simple "wait" command.
26-03-2018
When it passes, stdout ends with: main[1] --Done: test passed When it fails: Timeout refired 1200 times Before that there is quite a bit of logging for breakpoints, method exits, and stepping. They are exactly the same for the pass and failed cases. So it looks like for the most part the test is running properly, but just not terminating. On Solaris, stderr ends with the following whether or not it passes: --Finish execution with sending "quit" command to JDB --Sending cmd: quit --Quit cmd was sent --waitForFinish: Waiting for mydojdbCmds() to finish On linux it's a bit different. I see: --Finish execution with sending "quit" command to JDB --Sending cmd: quit --Quit cmd was sent --waitForFinish: Waiting for all processes to finish I'm not sure if this difference on Solaris is expected or related to the timeout issue.
26-03-2018
With mach5 testing, timed out 61 out of 100 times on solaris-sparc. Original issue in JDK-6902121 was reported on solaris-x86. Ran clean 100 times on Windows-x64, linux-x64, and macos-x64.
01-02-2018
I don't see any matching failures in JDK 9. We should try to reproduce in 11, and remove from ProblemList.txt if it does not reproduce.
19-01-2018
Copying rule from JDK-6902121 RULE com/sun/jdi/JdbMethodExitTest.sh Timeout any
19-01-2018