JDK-8209744 : com/sun/jdi/ClassesByName2Test.java fails with VMDisconnectedException in CDS mode
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 12
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2018-08-20
  • Updated: 2018-09-26
  • Resolved: 2018-09-26
Related Reports
Duplicate :  
JDK-8210926 - vmTestbase/nsk/jvmti/scenarios/allocation/AP11/ap11t001/TestDescription.java failed with JVMTI_ERROR_INVALID_CLASS in CDS mode
Relates :  
JDK-8202951 - Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary
Description
com/sun/jdi/ClassesByName2Test.java fails with VMDisconnectedException when running on a JDK binary with existing CDS archive:

com.sun.jdi.VMDisconnectedException
	at jdk.jdi/com.sun.tools.jdi.TargetVM.waitForReply(TargetVM.java:310)
	at jdk.jdi/com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(VirtualMachineImpl.java:1145)
	at jdk.jdi/com.sun.tools.jdi.PacketStream.waitForReply(PacketStream.java:87)
	at jdk.jdi/com.sun.tools.jdi.JDWP$VirtualMachine$AllClassesWithGeneric.waitForReply(JDWP.java:1612)
	at jdk.jdi/com.sun.tools.jdi.JDWP$VirtualMachine$AllClassesWithGeneric.process(JDWP.java:1598)
	at jdk.jdi/com.sun.tools.jdi.VirtualMachineImpl.retrieveAllClasses(VirtualMachineImpl.java:1115)
	at jdk.jdi/com.sun.tools.jdi.VirtualMachineImpl.allClasses(VirtualMachineImpl.java:331)
	at ClassesByName2Test.runTests(ClassesByName2Test.java:163)
	at TestScaffold.startTests(TestScaffold.java:431)
	at ClassesByName2Test.main(ClassesByName2Test.java:123)
	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.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:246)
	at java.base/java.lang.Thread.run(Thread.java:834)
Comments
I put an assert for NULL in JvmtiEnv::GetClassStatus() but never hit it even though I reproduced the failure. Turns out this is a redundant check, and the null is actually caught by the jvmti_GetClassStatus() wrapper function (which is annoyingly generated from an xsl file). I managed to add the assert there, and got a backtrace. V [libjvm.dylib+0xc6ab07] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x47 V [libjvm.dylib+0x45c20b] report_vm_error(char const*, int, char const*, char const*, ...)+0xcc V [libjvm.dylib+0x814bb1] jvmti_GetClassStatus(_jvmtiEnv*, _jclass*, int*)+0x262 C [libjdwp.dylib+0x24beb] classStatus+0x67 C [libjdwp.dylib+0xa169] allClasses1+0xa3 C [libjdwp.dylib+0x9daa] allClassesWithGeneric+0x14 C [libjdwp.dylib+0xe921] debugLoop_run+0x1f4 C [libjdwp.dylib+0x1faad] attachThread+0x4c V [libjvm.dylib+0x87a8e4] JvmtiAgentThread::call_start_function()+0x3c V [libjvm.dylib+0xbdf3a0] JavaThread::thread_main_inner()+0x1fe V [libjvm.dylib+0xbdee7b] JavaThread::run()+0x313 V [libjvm.dylib+0xa3bbd8] thread_native_entry(Thread*)+0x145 C [libsystem_pthread.dylib+0x405a] _pthread_body+0x83 C [libsystem_pthread.dylib+0x3fd7] _pthread_body+0x0 C [libsystem_pthread.dylib+0x13ed] thread_start+0xd allClasses1() calls allLoadedClasses(), which calls JVMTI JvmtiEnv::GetLoadedClasses(). So it seems likely this is the same as JDK-8210926.
23-09-2018
I would need to get a backtrace first to determine that.
21-09-2018
To run the test locally with jtreg, do 'bin/java -Xshare:dump -Xms128m -Xmx128m' before executing the test using jtreg. To test via mach5, please apply the patch http://cr.openjdk.java.net/~jiangli/8202951/webrev.02/. A default CDS archive is created at JDK build with the patch.
21-09-2018
Could this be the same issue as JDK-8210926? Is the null mirror from the classes array returned by JvmtiEnv::GetLoadedClasses()?
21-09-2018
[~cjplummer]Please ignore my recent tests (this week). I added debugging output in the VM but with no resource mark. Sorry for the noises.
21-09-2018
BTW, can someone tell me how to run this test in CDS mode.
21-09-2018
I don't know the class loading code very well. Anyone care to share some hints as to why the Klass of the mirror would return NULL? Possibly it's an oop but not for a java.lang.Class? // k_mirror - may be primitive, this must be checked // status_ptr - pre-checked for NULL jvmtiError JvmtiEnv::GetClassStatus(oop k_mirror, jint* status_ptr) { jint result = 0; if (java_lang_Class::is_primitive(k_mirror)) { result |= JVMTI_CLASS_STATUS_PRIMITIVE; } else { Klass* k = java_lang_Class::as_Klass(k_mirror); NULL_CHECK(k, JVMTI_ERROR_INVALID_CLASS); result = k->jvmti_class_status(); } *status_ptr = result; return JVMTI_ERROR_NONE; } /* end GetClassStatus */ Perhaps the best next step would be to put some debugging code in the error case above and try to get some info on the mirror. Another useful thing to do would be to call pns2() to get a native backtrace when this happens. We know the jdwp classStatus() function is the callee, but it is just passing the jclass passed to it. Would be good to know where that came from.
21-09-2018
I looks like there are a very large number of recent failures with Jiangli's runs with the error: Exception: com.sun.jdi.VMDisconnectedException Crash: Internal Error ...resourceArea.inline.hpp...fatal error: memory leak: allocating without ResourceMark I assume this is a different issue caused by changes local to Jiangli's repo. I've updated the search above to prune out these failures. That leaves 3 that fail with just the error message: Exception: com.sun.jdi.VMDisconnectedException Two on sparc, one on mac. These are also just with Jiangli's runs. In all 3 cases the logfile shows: JDWP exit error JVMTI_ERROR_INVALID_CLASS(21): on getting class status [:1283] FATAL ERROR in native method: JDWP on getting class status, jvmtiError=JVMTI_ERROR_INVALID_CLASS(21) Current thread is 10 Dumping core ... And looking at the top of the exception that is mentioned in the bug description: com.sun.jdi.VMDisconnectedException at jdk.jdi/com.sun.tools.jdi.TargetVM.waitForReply(TargetVM.java:310) at jdk.jdi/com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(VirtualMachineImpl.java:1145) It becomes clear that the disconnect happened because of a timeout due to the fatal error (which core dumps the process). So what really needs to be investigated here is why the JVMTI_ERROR_INVALID_CLASS is happening.
21-09-2018
The reported failure is the only one to date and further attempts to reproduce it have failed. Closing as CNR for now. Can be re-opened if it happens again.
11-09-2018