JDK-8246493 : JDI stress/serial/mixed002 needs to use WhiteBox.deflateIdleMonitors support
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2020-06-03
  • Updated: 2024-11-13
  • Resolved: 2020-06-30
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 16
16 b04Fixed
Related Reports
Relates :  
JDK-8153224 - Monitor deflation prolong safepoints
Sub Tasks
JDK-8248354 :  
ProblemList vmTestbase/nsk/jdi/stress/serial/mixed002/TestDescription.java - Resolved
Description
The following test failed in the JDK15 CI:

vmTestbase/nsk/jdi/stress/serial/mixed002/TestDescription.java

Here's a snippet from the log file:

Thread state: 0
Debugger nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn003.forceEarlyReturn003@584cc551 finished successfully
debugee.stderr> Debuggee: received the command: quit
debugee.stderr> Debuggee: exiting
debugee.stderr> Debuggee nsk.share.jdi.AbstractJDIDebuggee@4e515669 finished successfully
debugee.stderr> Debuggee nsk.share.jdi.SerialExecutionDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: COMMAND_CLEAR_DEBUGGEE
debugee.stderr> Debuggee nsk.share.jdi.SerialExecutionDebuggee : sending the command: ready
Execute debugger: nsk.jdi.ThreadReference.ownedMonitorsAndFrames.ownedMonitorsAndFrames001.ownedMonitorsAndFrames001@7025bdc7
debugee.stderr> Debuggee: received the command: COMMAND_EXECUTE_DEBUGGEE:nsk.share.jdi.AbstractJDIDebuggee
debugee.stderr> Debuggee nsk.share.jdi.AbstractJDIDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: createStateTestThread
debugee.stderr> Debuggee nsk.share.jdi.AbstractJDIDebuggee : sending the command: ready
# ERROR: Test bug in nsk.jdi.ThreadReference.ownedMonitorsAndFrames.ownedMonitorsAndFrames001.ownedMonitorsAndFrames001@7025bdc7: nsk.share.TestBug: There are more than one(2) instance of 'nsk.share.jpda.StateTestThread in debuggee
nsk.share.TestBug: There are more than one(2) instance of 'nsk.share.jpda.StateTestThread in debuggee
	at nsk.share.jdi.TestDebuggerType2.findSingleObjectReference(TestDebuggerType2.java:264)
	at nsk.jdi.ThreadReference.ownedMonitorsAndFrames.ownedMonitorsAndFrames001.ownedMonitorsAndFrames001.doTest(ownedMonitorsAndFrames001.java:104)
	at nsk.share.jdi.SerialExecutionDebugger.executeTests(SerialExecutionDebugger.java:294)
	at nsk.share.jdi.SerialExecutionDebugger.doTest(SerialExecutionDebugger.java:233)
	at nsk.share.jdi.TestDebuggerType2.runIt(TestDebuggerType2.java:214)
	at nsk.share.jdi.SerialExecutionDebugger.main(SerialExecutionDebugger.java:65)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at PropertyResolvingWrapper.main(PropertyResolvingWrapper.java:102)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:832)
debugee.stderr> Debuggee: received the command: quit
debugee.stderr> Debuggee: exiting
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/a4585ab8c15f User: dcubed Date: 2020-06-30 19:43:50 +0000
30-06-2020
Please note that the proposed fix for this bug uses WhiteBox.deflateIdleMonitors() support which is not in JDK15. That support was added in JDK16 (by JDK-8246477) and is included with another change (getting rid of the special deflation request mechanism) that is not appropriate for JDK15. Short version: I don't recommend back porting this test fix to JDK15.
29-06-2020
Here's the logs from my jdk-15+29 stress testing sightings: $ unzip -l jdk-15+29_linux.8246493.zip Archive: jdk-15+29_linux.8246493.zip Length Date Time Name --------- ---------- ----- ---- 99929 06-25-2020 14:56 jdk-15+29_1/failures.linux-x86_64/TestDescription.jtr.fastdebug --------- ------- 99929 1 file
29-06-2020
Was able to reproduce the failure on my Linux-X64 server by running the test with fastdebug bits in a loop for 100 runs. > All runs done; pass_count=95; fail_count=5
26-06-2020
[~cjplummer] - Nice sleuthing job! I'll take a look at this tomorrow.
26-06-2020
This is pretty easy to reproduce. Maybe 1 in 10 to 15 runs will fail. I ran against builds starting on June 2nd and earlier and found that it was introduced with jdk-15-1263. Changesets include: 2020-06-01 20:37 dcubed: 629b14 - OpenJDK 8153224 Monitor deflation prolong safepoints 2020-06-01 20:34 pli: c0e7b9 - OpenJDK 8245158 C2: Enable SLP for some manually unrolled loops There was also a closed changed that doesn't seem relevant. I think JDK-8153224 is the likely culprit here. The summary kind of sticks out: Summary: Add support for AsyncDeflateIdleMonitors (default true); the async deflation work is performed by the ServiceThread. The problem goes away with -XX:-AsyncDeflateIdleMonitors. Looking at the test failure: nsk.share.TestBug: There are more than one(2) instance of 'nsk.share.jpda.StateTestThread in debuggee And then in StateTestThread.java: /* * StateTestThread sequentially switches its state in following order: * - thread not started * - thread is running * - thread is sleeping * - thread in Object.wait() * - thread wait on java monitor * - thread is finished * * To use this class create new instance of StateTestThread and sequentially call method nextState(). */ public class StateTestThread extends Thread { [~dcubed]I wonder if delaying monitor deflation is keeping the Thread object alive longer than the test expects.
25-06-2020
This failure mode first appeared 2020-06-02, a day before filed. It's failed quite often since then.
25-06-2020
Here's the logs from my jdk-15+26 stress testing sightings: $ unzip -l jdk-15+26_linux.8246493.zip Archive: jdk-15+26_linux.8246493.zip Length Date Time Name --------- ---------- ----- ---- 92322 2020-06-04 13:19 jdk-15+26_1/failures.linux-x86_64/TestDescription.jtr.fastdebug --------- ------- 92322 1 file
08-06-2020