JDK-8253073 : jdi/stress/serial/heapwalking002 failed with "ERROR: Unexpected size of referenceType.instances(java.lang.Thread): 11, expected: 10"
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 16
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux
  • CPU: x86_64
  • Submitted: 2020-09-12
  • Updated: 2023-08-16
  • Resolved: 2023-08-16
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.
Other
tbdResolved
Related Reports
Relates :  
JDK-8176567 - nsk/jdi/ReferenceType/instances/instances002: TestFailure: Unexpected size of referenceType.instances(nsk.share.jdi.TestInterfaceImplementer1): 11, expected: 10
Description
The following test failed in the JDK16 CI:

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

Here's a snippet from the log file:

Execute debugger: nsk.jdi.ObjectReference.referringObjects.referringObjects003.referringObjects003@7b81b100
debugee.stderr> Debuggee: received the command: COMMAND_EXECUTE_DEBUGGEE:nsk.jdi.ObjectReference.referringObjects.referringObjects003.referringObjects003a
debugee.stderr> Debuggee nsk.jdi.ObjectReference.referringObjects.referringObjects003.referringObjects003a : sending the command: ready
debugee.stderr> Debuggee: received the command: startThreads:15
debugee.stderr> Debuggee nsk.jdi.ObjectReference.referringObjects.referringObjects003.referringObjects003a : sending the command: ready
debugee.stderr> Debuggee: received the command: stopThreads
debugee.stderr> Debuggee nsk.jdi.ObjectReference.referringObjects.referringObjects003.referringObjects003a : sending the command: ready
# ERROR: Unexpected size of referenceType.instances(java.lang.Thread): 11, expected: 10
The following stacktrace is for failure analysis.
nsk.share.TestFailure: Unexpected size of referenceType.instances(java.lang.Thread): 11, expected: 10
	at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:428)
	at nsk.share.Log.complain(Log.java:399)
	at nsk.share.jdi.HeapwalkingDebugger.checkDebugeeAnswer_instances(HeapwalkingDebugger.java:116)
	at nsk.jdi.ObjectReference.referringObjects.referringObjects003.referringObjects003.doTest(referringObjects003.java:183)
	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: forceGC
debugee.stderr> Debuggee nsk.jdi.ObjectReference.referringObjects.referringObjects003.referringObjects003a : sending the command: ready
debugee.stderr> Debuggee: received the command: forceGC
debugee.stderr> Debuggee nsk.jdi.ObjectReference.referringObjects.referringObjects003.referringObjects003a : sending the command: ready
# ERROR: Debugger nsk.jdi.ObjectReference.referringObjects.referringObjects003.referringObjects003@7b81b100 finished with errors
debugee.stderr> Debuggee: received the command: quit
debugee.stderr> Debuggee: exiting
debugee.stderr> Debuggee nsk.jdi.ObjectReference.referringObjects.referringObjects003.referringObjects003a@515f550a 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
debugee.stderr> Debuggee: received the command: quit
debugee.stderr> Debuggee: exiting
Debuggee's process finished with status: 95
TEST FAILED


#>  
#>  SUMMARY: Following errors occured
#>      during test execution:
#>  
# ERROR: Unexpected size of referenceType.instances(java.lang.Thread): 11, expected: 10
# ERROR: Debugger nsk.jdi.ObjectReference.referringObjects.referringObjects003.referringObjects003@7b81b100 finished with errors
----------System.err:(0/0)----------
Comments
This CR has not reproduced in 3 years. Closing as CNR.
16-08-2023
I doubt this has the same root cause as JDK-8176567, which results in the object returned by the last cal to ClassType.newInstance() still being live after doing a resume and calling ReferenceType.instances(). In the case of this test we are counting Thread (and ThreadGroup) references, not newly created instances. The top of the test starts with the following: // threads and thread groups loaded before debugger command should be // filtered List<ObjectReference> threadGroupsToFilter = HeapwalkingDebugger.getObjectReferences( "java.lang.ThreadGroup", vm); List<ObjectReference> threadsToFilter = HeapwalkingDebugger.getObjectReferences("java.lang.Thread", vm); And the failure is later on during the following call: checkDebugeeAnswer_instances("java.lang.Thread", threadsToFilter.size()); I suspect a VM thread that is created on startup just got started a bit late, and started after building threadsToFilter. It would be useful if the test printed out info about the extra Thread found.
03-01-2022