JDK-8210512 : [Testbug] vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-09-07
  • Updated: 2022-06-01
  • Resolved: 2018-09-10
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 12
11.0.7Fixed 12 b11Fixed
Related Reports
Relates :  
JDK-8209361 - [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1)
Description
vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with following error in tier5 test on various platforms:

# ERROR: Unexpected size of ClassLoaderReference.referringObjects: 17, expected: 16
The following stacktrace is for failure analysis.
nsk.share.TestFailure: Unexpected size of ClassLoaderReference.referringObjects: 17, expected: 16
	at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:428)
	at nsk.share.Log.complain(Log.java:399)
	at nsk.jdi.ObjectReference.referringObjects.referringObjects002.referringObjects002.checkClassObjectReferrersCount(referringObjects002.java:103)
	at nsk.jdi.ObjectReference.referringObjects.referringObjects002.referringObjects002.doTest(referringObjects002.java:125)
	at nsk.share.jdi.TestDebuggerType2.runIt(TestDebuggerType2.java:214)
	at nsk.jdi.ObjectReference.referringObjects.referringObjects002.referringObjects002.run(referringObjects002.java:86)
	at nsk.jdi.ObjectReference.referringObjects.referringObjects002.referringObjects002.main(referringObjects002.java:82)
	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:566)
	at PropertyResolvingWrapper.main(PropertyResolvingWrapper.java:104)
	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:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:834)
Comments
This is a test fix for an issue that popped up after JDK-8209361 was backported (for 11.0.7-oracle parity)
05-12-2019
Fix request (11u) I would like to downport this for parity with 11.0.7-oracle. Applies clean.
05-12-2019
URL: http://hg.openjdk.java.net/jdk/jdk/rev/9d89c0835ac1 User: dholmes Date: 2018-09-10 23:01:10 +0000
10-09-2018
I've been convinced this is actually a testbug and that the self-reference should be accounted for. So I will update the test.
10-09-2018
I don't think this can cause an infinite loop during heap walking, whether it is actually resolved or we treat it as resolved. The "this_class" entry is eagerly resolved for unsafe-anonymous classes, and unless I am missing something, I would expect it to be explicitly resolved by any class that references its own fields or methods (consider a recursive method).
10-09-2018
Every class contains a self-referential entry in the CP: this_class. That entry is never explicitly resolved (at least I can't see how it would be) but in any case it should not count as a live reference to the current class. I could see this potentially causing an infinite loop in a heap-walking algorithm. My suggested fix is to skip the this_class entry in the CP: diff -r 5a1be00ea4f6 src/hotspot/share/prims/jvmtiTagMap.cpp --- a/src/hotspot/share/prims/jvmtiTagMap.cpp +++ b/src/hotspot/share/prims/jvmtiTagMap.cpp @@ -2891,7 +2891,7 @@ assert(tag.is_unresolved_klass(), "must be"); constantPoolHandle cp(Thread::current(), pool); Klass* klass = ConstantPool::klass_at_if_loaded(cp, i); - if (klass == NULL) { + if (klass == NULL || klass == ik) { continue; } entry = klass->java_mirror();
10-09-2018
referringObjects list before the fix: 1: instance of java.lang.ref.SoftReference(id=799) 2: instance of nsk.share.ReferringObject(id=800) 3: instance of nsk.share.jdi.TestClass1(id=801) 4: instance of nsk.share.jdi.TestClass1(id=802) 5: instance of nsk.share.jdi.TestClass1(id=803) 6: instance of nsk.share.jdi.TestClass1(id=804) 7: instance of nsk.share.jdi.TestClass1(id=805) 8: instance of nsk.share.jdi.TestClass1(id=806) 9: instance of nsk.share.jdi.TestClass1(id=807) 10: instance of nsk.share.jdi.TestClass1(id=808) 11: instance of nsk.share.jdi.TestClass1(id=809) 12: instance of nsk.share.jdi.TestClass1(id=810) 13: instance of java.lang.ref.WeakReference(id=811) 14: instance of java.lang.ref.PhantomReference(id=812) 15: instance of java.lang.Object[10] (id=813) 16: instance of java.lang.Object[10] (id=814) and after: 1: instance of java.lang.ref.SoftReference(id=799) 2: instance of nsk.share.ReferringObject(id=800) 3: instance of nsk.share.jdi.TestClass1(id=801) 4: instance of nsk.share.jdi.TestClass1(id=802) 5: instance of nsk.share.jdi.TestClass1(id=803) 6: instance of nsk.share.jdi.TestClass1(id=804) 7: instance of nsk.share.jdi.TestClass1(id=805) 8: instance of nsk.share.jdi.TestClass1(id=806) 9: instance of nsk.share.jdi.TestClass1(id=807) 10: instance of nsk.share.jdi.TestClass1(id=808) 11: instance of nsk.share.jdi.TestClass1(id=809) 12: instance of nsk.share.jdi.TestClass1(id=810) 13: instance of java.lang.ref.WeakReference(id=811) 14: instance of java.lang.ref.PhantomReference(id=812) 15: instance of java.lang.Object[10] (id=813) 16: instance of java.lang.Object[10] (id=814) 17: instance of java.lang.Class(reflected class=nsk.share.jdi.TestClass1, id=792) So it is the final Class instance that seems to be the problem.
10-09-2018
Test fails locally as soon as JDK-8209361 is applied. Will probably take some effort to discover exactly where the extra reference now comes from.
10-09-2018
This will likely be due to the change in JDK-8209361 which will now treat an unresolved CP entry as resolved if the target class is loaded. This is legal (as it just gives the appearance of eager resolution) but may surprise simple tests that think they can count all expected references.
10-09-2018