Bug ID: JDK-8024865 nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 fails since HSX25-B49

JDK-8024865 : nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 fails since HSX25-B49

Type: Bug
Component: core-svc
Sub-Component: debugger
Affected Version: hs25,8

Priority: P4
Status: Closed
Resolution: Duplicate
OS: generic
CPU: generic

Submitted: 2013-09-16
Updated: 2023-12-14
Resolved: 2014-10-28

Versions (Unresolved/Resolved/Fixed)

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

Duplicate :	JDK-6988950 - JDWP exit error JVMTI_ERROR_WRONG_PHASE(112)
Relates :	JDK-6988950 - JDWP exit error JVMTI_ERROR_WRONG_PHASE(112)

Description

These failures were spotted in the HSX-25-B49 snapshot PIT, in the 2013-09-13
RT_Baseline nightly after the Main_Baseline sync-down job, and in various
Aurora AdHoc jobs.

JDK: Java(TM) SE Runtime Environment 1.8.0 b106 (1.8.0-ea-fastdebug-b106)
VM:  Java HotSpot(TM) 64-Bit Server VM 25.0 b49 (25.0-b49-internal-201309061805.jcoomes.hs25-b49-snapshot-fastdebug) 

nsk/jdi/VirtualMachine/instanceCounts/instancecounts002

    This test failed due to the following:

[2013-09-06T23:07:22.47] debugee.stderr> Debuggee: exiting
[2013-09-06T23:07:22.48] debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283]
[2013-09-06T23:07:22.48] debugee.stderr> JDWP exit error JVMTI_ERROR_INVALID_ENVIRONMENT(116): Can't allocate jvmti memory [util.c:1797]
[2013-09-06T23:07:22.48] debugee.stderr> ERROR: JDWP unable to dispose of JVMTI environment: JVMTI_ERROR_INVALID_ENVIRONMENT(116)
[2013-09-06T23:07:22.48] debugee.stdout> FATAL ERROR in native method: JDWP Can't allocate jvmti memory, jvmtiError=JVMTI_ERROR_INVALID_ENVIRONMENT(116)
[2013-09-06T23:07:22.48] debugee.stdout> FATAL ERROR in native method: JDWP on getting class status, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
[2013-09-06T23:07:22.48] debugee.stdout> ## nof_mallocs = 156027, nof_frees = 140173
[2013-09-06T23:07:22.48] debugee.stdout> ## memory stomp: byte at 0x00000001006dd798 in front of object 0x00000001006dd7b0
[2013-09-06T23:07:22.48] debugee.stdout> #
[2013-09-06T23:07:22.49] debugee.stdout> # A fatal error has been detected by the Java Runtime Environment:
[2013-09-06T23:07:22.49] debugee.stdout> #
[2013-09-06T23:07:22.49] debugee.stdout> #  SIGBUS (0xa) at pc=0xffffffff7d6e3420, pid=8211, tid=15
[2013-09-06T23:07:22.49] debugee.stdout> #
[2013-09-06T23:07:22.49] debugee.stdout> # JRE version: Java(TM) SE Runtime Environment (8.0-b106) (build 1.8.0-ea-fastdebug-b106)
[2013-09-06T23:07:22.49] debugee.stdout> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b49-internal-201309061805.jcoomes.hs25-b49-snapshot-fastdebug mixed mode solaris-sparc compressed oops)
[2013-09-06T23:07:22.49] debugee.stdout> # Problematic frame:
[2013-09-06T23:07:22.49] debugee.stdout> # V  [libjvm.so+0xee3420]Current thread is 17
[2013-09-06T23:07:22.49] debugee.stdout> Dumping core ...


RULE nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 ExitCode 97

Comments

I'm closing this bug as a dup of the older issue: https://bugs.openjdk.java.net/browse/JDK-6988950 While this one looks like a regression, in fact, it only became visible in the B49. The root cause of the problem was always present. However, some additional conditions are necessary for the bug to become reproducible. The test failures and the analysis placed in this bug report are still very useful for the bug JDK-6988950.
28-10-2014
I was not able to reproduce the failure by running the tests: nsk/jdi/ObjectReference/referringObjects/referringObjects003 nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001 nsk/jdi/ClassObjectReference/toString/tostring001 nsk/jdi/ReferenceType/instances/instances005 nsk/jdi/stress/serial/ownedMonitorsAndFrames001 and with the jdk8 b109: /java/re/jdk/1.8.0/promoted/all/b109/binaries/solaris-amd64/fastdebug It does not mean they are not reproducible with this build as we saw these tests failing in the nightly. It only means these test failures are hard to reproduce. I also was not able to reproduce the above tests failures with the latest 8u40 build b11 in 1000 runs: /java/re/jdk/8u40/promoted/all/b11/binaries/solaris-amd64/fastdebug
23-10-2014
Reproduced the same failure mode on the test VMOutOfMemoryException001 with the jdk 8 build b111. This is a pstack dump: core 'core' of 20510: /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b111/binaries/sol ----------------- lwp# 1 / thread# 1 -------------------- ffff80ffbf51e75a __lwp_wait () + a ffff80ffbf51158c _thrp_join () + 60 ffff80ffbf5116da thr_join () + e ffff80fe4df3d588 ContinueInNewThread0 () + 44 ffff80fe4df3b707 ContinueInNewThread () + ab ffff80fe4df3d5f9 JVMInit () + 49 ffff80fe4df37d15 JLI_Launch () + 2c9 0000000000400b1b main () + 77 000000000040093c ???????? () + fffffffffffffe98 ----------------- lwp# 2 / thread# 2 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4d508822 void VMThread::execute(VM_Operation) () + 3e6 ffff80fe4c2f75a9 void vm_exit(int) () + 91 ffff80fe4c64ba07 JVM_Halt () + 2e3 ffff80fe4ac347c3 Java_java_lang_Shutdown_halt0 () + b ffff80ffa723b526 * java/lang/Shutdown.halt0(I)V+0 ffff80ffa72064d8 * java/lang/Shutdown.halt(I)V+7 (line 277) ffff80ffa72064d8 * java/lang/Shutdown.exit(I)V+99 (line 395) ffff80ffa72064d8 * java/lang/Runtime.exit(I)V+14 (line 214) ffff80ffa72064d8 * java/lang/System.exit(I)V+4 (line 1930) ffff80ffa72064d8 * nsk/share/jpda/AbstractDebuggeeTest.doTest()V+210 (line 597) ffff80ffa72064d8 * nsk/share/jdi/AbstractJDIDebuggee.main([Ljava/lang/String;)V+14 (line 32) ffff80ffa72006ad * nsk/share/jdi/AbstractJDIDebuggee.main([Ljava/lang/String;)V+-10704 (line 33) ffff80fe4c303f3e void JavaCalls::call_helper(JavaValue,methodHandle,JavaCallArguments,Thread) () + 1622 ffff80fe4c3028db void JavaCalls::call(JavaValue,methodHandle,JavaCallArguments,Thread) () + 3f ffff80fe4c4717dc void jni_invoke_static(JNIEnv_,JavaValue,_jobject,JNICallType,_jmethodID,JNI_ArgumentPusher,Thread) () + b80 ffff80fe4c4d1389 jni_CallStaticVoidMethod () + 765 ffff80fe4df37fc3 JavaMain () + 287 ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 3 / thread# 3 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 4 / thread# 4 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 5 / thread# 5 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 6 / thread# 6 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 7 / thread# 7 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 8 / thread# 8 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 9 / thread# 9 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 10 / thread# 10 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 11 / thread# 11 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 12 / thread# 12 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 13 / thread# 13 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 14 / thread# 14 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 15 / thread# 15 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4be95418 GCTaskGCTaskManager::get_task(unsigned) () + 31c ffff80fe4be9af2b void GCTaskThread::run() () + 4a7 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 16 / thread# 16 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4d1219ed void SafepointSynchronize::begin() () + e75 ffff80fe4d507ada void VMThread::loop() () + 85a ffff80fe4d5068f2 void VMThread::run() () + b6 ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 17 / thread# 17 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4ce78c8a void ObjectMonitor::wait(long,bool,Thread) () + 4fe ffff80fe4d2aa4b8 void ObjectSynchronizer::wait(Handle,long,Thread) () + 304 ffff80fe4c652f5f JVM_MonitorWait () + 763 ffff80ffa723b526 * java/lang/Object.wait(J)V+0 ffff80ffa72064d8 * java/lang/Object.wait()V+2 (line 1004) ffff80ffa72064d8 * java/lang/ref/Reference$ReferenceHandler.run()V+36 (line 276) ffff80ffa72006ad * java/lang/ref/Reference$ReferenceHandler.run()V+-16432 ffff80fe4c303f3e void JavaCalls::call_helper(JavaValue,methodHandle,JavaCallArguments,Thread) () + 1622 ffff80fe4c3028db void JavaCalls::call(JavaValue,methodHandle,JavaCallArguments,Thread) () + 3f ffff80fe4c2ffc88 void JavaCalls::call_virtual(JavaValue,KlassHandle,Symbol,Symbol,JavaCallArguments,Thread) () + 77c ffff80fe4c3004d9 void JavaCalls::call_virtual(JavaValue,Handle,KlassHandle,Symbol,Symbol,Thread) () + ed ffff80fe4c6d56eb void thread_entry(JavaThread,Thread) () + c7 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 18 / thread# 18 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4ce78c8a void ObjectMonitor::wait(long,bool,Thread) () + 4fe ffff80fe4d2aa4b8 void ObjectSynchronizer::wait(Handle,long,Thread) () + 304 ffff80fe4c652f5f JVM_MonitorWait () + 763 ffff80ffa723b526 * java/lang/Object.wait(J)V+0 ffff80ffa72064d8 * java/lang/ref/ReferenceQueue.remove(J)Ljava/lang/ref/Reference;+44 (line 277) ffff80ffa7206654 * java/lang/ref/ReferenceQueue.remove()Ljava/lang/ref/Reference;+2 (line 316) ffff80ffa7206654 * java/lang/ref/Finalizer$FinalizerThread.run()V+16 (line 373) ffff80ffa72006ad * java/lang/ref/Finalizer$FinalizerThread.run()V+-28960 ffff80fe4c303f3e void JavaCalls::call_helper(JavaValue,methodHandle,JavaCallArguments,Thread) () + 1622 ffff80fe4c3028db void JavaCalls::call(JavaValue,methodHandle,JavaCallArguments,Thread) () + 3f ffff80fe4c2ffc88 void JavaCalls::call_virtual(JavaValue,KlassHandle,Symbol,Symbol,JavaCallArguments,Thread) () + 77c ffff80fe4c3004d9 void JavaCalls::call_virtual(JavaValue,Handle,KlassHandle,Symbol,Symbol,Thread) () + ed ffff80fe4c6d56eb void thread_entry(JavaThread,Thread) () + c7 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 20 / thread# 20 -------------------- ffff80ffbf4d475d _ndoprnt () + 1c5 ffff80ffbf4da588 vsnprintf () + 74 ffff80fe4cecf312 int local_vsnprintf(char,unsigned long,const char,__va_list_element) () + ee ffff80fe4c6d53d9 jio_snprintf () + 95 ffff80fe4bc11d33 void report_fatal(const char,int,const char) () + 4df ffff80fe4cea51bf void os::free(void,unsigned short) () + 30f ffff80fe4cfb4eef void PerfDataManager::destroy() () + b3 ffff80fe4cfbc3bb void perfMemory_exit() () + 3f ffff80fe4cebb03c void os::abort(bool) () + 14 ffff80fe4c46a36c jni_FatalError () + 6f8 ffff80fe4ab88d5e jniFatalError () + ba ffff80fe4ab8a72e debugInit_exit () + ee ffff80fe4aba300c classStatus () + ec ffff80fe4ab84066 classesForSignature () + ae ffff80fe4ab8a97d debugLoop_run () + 1b1 ffff80fe4ab9e49d connectionInitiated () + 8d ffff80fe4ab9e6ed attachThread () + 51 ffff80fe4c895ad5 void JvmtiAgentThread::start_function_wrapper(JavaThread,Thread) () + 219 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 21 / thread# 21 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4c8a4373 int JvmtiRawMonitor::raw_wait(long,bool,Thread) () + 267 ffff80fe4c81591d jvmtiError JvmtiEnv::RawMonitorWait(JvmtiRawMonitor,long) () + c1 ffff80fe4aba2822 debugMonitorWait () + 2a ffff80fe4ab92631 dequeueCommand () + 91 ffff80fe4ab933b3 commandLoop () + 53 ffff80fe4c895ad5 void JvmtiAgentThread::start_function_wrapper(JavaThread,Thread) () + 219 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 22 / thread# 22 -------------------- ffff80ffbf51e72a __lwp_sigqueue () + a ffff80ffbf4c291d raise () + 19 ffff80ffbf497ff2 abort () + ca ffff80fe4cebb141 void os::abort(bool) () + 119 ffff80fe4c46a36c jni_FatalError () + 6f8 ffff80fe4ab88d5e jniFatalError () + ba ffff80fe4ab8a72e debugInit_exit () + ee ffff80fe4aba483a jvmtiAllocate () + b6 ffff80fe4ab31e64 setLastError () + c4 ffff80fe4ab32ba7 socketTransport_readPacket () + 73 ffff80fe4ab9ece7 transport_receivePacket () + 27 ffff80fe4ab8ab05 reader () + 71 ffff80fe4c895ad5 void JvmtiAgentThread::start_function_wrapper(JavaThread,Thread) () + 219 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 23 / thread# 23 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 24 / thread# 24 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 25 / thread# 25 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 26 / thread# 26 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 27 / thread# 27 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 28 / thread# 28 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 29 / thread# 29 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 30 / thread# 30 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 31 / thread# 31 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 32 / thread# 32 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 33 / thread# 33 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 34 / thread# 34 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd8026c bool Monitor::wait(bool,long,bool) () + 584 ffff80fe4bae3d02 CompileTaskCompileQueue::get() () + fa ffff80fe4bae673a void CompileBroker::compiler_thread_loop() () + 1e6 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start () ----------------- lwp# 35 / thread# 35 -------------------- ffff80ffbf51e7fa ___lwp_cond_wait () + a ffff80fe4ced0905 void os::PlatformEvent::park() () + cd ffff80fe4cd7a6da int Monitor::IWait(Thread,long) () + 37e ffff80fe4cd80351 bool Monitor::wait(bool,long,bool) () + 669 ffff80fe4d1305d4 void ServiceThread::service_thread_entry(JavaThread,Thread*) () + 1d4 ffff80fe4d349b79 void JavaThread::thread_main_inner() () + 521 ffff80fe4d34928f void JavaThread::run() () + 84f ffff80fe4ceb8366 java_start () + 1ce ffff80ffbf5151f1 _thrp_setup () + a5 ffff80ffbf515490 _lwp_start ()
23-10-2014
The following tests are also listed in this bug report: As well reproducible (I have not been able to reproduce them now): nsk/jdi/ObjectReference/referringObjects/referringObjects003 nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001 As NOT well reproducible: nsk/jdi/ClassObjectReference/toString/tostring001 nsk/jdi/ReferenceType/instances/instances005 This test also failed in the 2013.09.26 RT_Baseline nightly (reported by Zhengyu Gu): nsk/jdi/stress/serial/ownedMonitorsAndFrames001 I will check these tests before closing this issue as "Not reproducible".
23-10-2014
Interesting that it is harder (or maybe, impossible) to reproduce the failure with the product (non-fastdebug) bits: /java/re/jdk/1.8.0/promoted/all/b111/binaries/solaris-amd64
22-10-2014
The test instancecounts002 failure is reproducible with the build: /java/re/jdk/1.8.0/promoted/all/b111/binaries/solaris-amd64/fastdebug However, it is NOT reproducible with the build: /java/re/jdk/1.8.0/promoted/all/b112/binaries/solaris-amd64/fastdebug It is also NOT reproducible with the 8u40 builds: /java/re/jdk/8u40/promoted/all/b01/binaries/solaris-amd64/fastdebug /java/re/jdk/8u40/promoted/all/b11/binaries/solaris-amd64/fastdebug
22-10-2014
I can not reproduce this bug with the jdk 9 bits (checked builds: b01, b18, b35) and 1000 runs. However, it is easily reproducible with one of my own jdk 8 build. It is possible that this bug was fixed by one of the integration in the last year.. Otherwise, some fixes lowered the repro rate of the issue.
22-10-2014
For this particular issue the most interesting part of the shutdown sequence is in the hotspot runtime/java.cpp: void before_exit(JavaThread * thread) { . . . JvmtiExport::post_vm_death(); ==> this has been posted Threads::shutdown_vm_agents(); ==> this shutdown has been processed // Terminate the signal thread // Note: we don't wait until it actually dies. os::terminate_signal_thread(); print_statistics(); ==> The call stack shows the control is here - it is in the progress . . . } I'm looking for a workaround in the shutdown dance in a scenario when the dispose command has not been sent by the debugger. One possible way is to prevent any event processing activity from the point when the VM death event was posted. Not sure, if all such events can be blocked with some kind of synchronization. Another way would be to process the WRONG_PHASE error differently in the debugLoop_run(). In such a case, it is possible to check the VM phase with the JVMTI GetPhase() and then ignore or reject the debugger commands until the Dispose or Exit command is received, or something like that.
22-04-2014
RULE nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 Crash Internal Error ...vframe.cpp...assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack! RULE nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 Exception com.sun.jdi.VMDisconnectedException RULE nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 Exception java.net.SocketException: Broken pipe RULE nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 Exception java.net.SocketException: Connection reset RULE nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 Exception nsk.share.Failure: Caught IOException while writing an object to IOPipe connection: RULE nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 ExitCode 1
14-04-2014
2013.10.02 RT_Baseline nightly: nsk/jdi/ReferenceType/instances/instances002 [2013-10-03T03:50:38.96] TEST PASSED [2013-10-03T04:20:43.85] # Test level exit status: 151 Test run URL: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=300479.JAVASE.NIGHTLY.VM.RT_Baseline.2013-10-02-369#nsk.quick-jdi%20%5B!desktop%5D%20(tonga)_nsk/jdi/ReferenceType/instances/instances002 Host: sc11136610, Intel Xeon 3119 MHz, 2 cores, 8G, Win32 / Windows 7 Enterprise, Options: -server -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M RULE nsk/jdi/ReferenceType/instances/instances002 Timeout none
04-10-2013
It seems the issue is understandable now. Both the debugger and the debuggee (target VM) are at shutdown. It is why the JDWP agent gets the error JVMTI_ERROR_WRONG_PHASE(112). The debugger at this point is not expected to send any commands to the JDWP agent. But in fact, it did which was a puzzle to me. As occurred it is done at the call site matching the stack trace below: java.lang.Exception: MY_TRACE: trap in JDI retrieveClassesBySignature at com.sun.tools.jdi.VirtualMachineImpl.retrieveClassesBySignature(VirtualMachineImpl.java:939) at com.sun.tools.jdi.VirtualMachineImpl.removeReferenceType(VirtualMachineImpl.java:830) at com.sun.tools.jdi.InternalEventHandler.run(InternalEventHandler.java:60) at java.lang.Thread.run(Thread.java:724) The JDI VirtualMachineImpl starts the InternalEventHandler thread that handles the events: ClassUnloadEvent and ClassPrepareEvent In our case, it gets a ClassUnloadEvent. The InternalEventHandler wants to uncache the matching reference type. If there is more than one class with the same name (case of anonymous classes?), it can not distinguish them, and so, deletes all references and re-retrieve them again: MY_TRACE: JDI: VirtualMachineImpl.retrieveClassesBySignature: sig=Ljava/lang/invoke/LambdaForm$DMH; I see two issues here: - The test debugger gets out of sync with the JDI as it does not call vm.dispose() at the right point - The JDWP would be better to handle the WRONG_PHASE gracefully and return JDWP_ERROR(VM_DEAD) to the JDI
27-09-2013
2013.09.26 RT_Baseline nightly: nsk/jdi/stress/serial/ownedMonitorsAndFrames001 debugee.stderr> Debuggee: exiting debugee.stdout> FATAL ERROR in native method: JDWP on getting class status, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112) debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] # ERROR: TEST FAILED: debuggee's process finished with status: 1 Test run URL: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=295300.JAVASE.NIGHTLY.VM.RT_Baseline.2013-09-26-362 Host: sc11136445, Intel Xeon 3221 MHz, 2 cores, 8G, Win32 / Windows 7 Enterprise, Options: -client -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:NativeMemoryTracking=detail -XX:ReservedCodeCacheSize=256M RULE nsk/jdi/stress/serial/ownedMonitorsAndFrames001 ExitCode 97
27-09-2013
Checked the other failing tests. These two test failures are easily reproducible with the exactly the same pattern as instancecounts002: nsk/jdi/ObjectReference/referringObjects/referringObjects003 nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001 Was not able to reproduce the issue yet with these two tests: nsk/jdi/ClassObjectReference/toString/tostring001 nsk/jdi/ReferenceType/instances/instances005 Also, it looks strange that we do not see any jtreg tests with the same failure pattern. It might mean that the failure pattern depends on the NSK tests framework, specifically, because the debuggers of these tests do not shut down the JDWP agent with the vm.dispose() when they are done. Adding the vm.dispose() to debuggers works around the issue and the tests reliably pass.
24-09-2013
I've added my extra tracing with the keyword 'MY_TRACE' into the test on both debugger and debuggee side and see one important difference in behavior. This is a tail of tracing in the good case (before regression): debugee.stdout> MY_TRACE: HeapwalkingDebuggee.parseCommand: after DELETE_INSTANCES debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stdout> MY_TRACE: debugLoop: Command set 1, command 21 debugee.stdout> MY_TRACE: debugLoop: Command set 1, command 21 - Done! MY_TRACE: checkDebugeeAnswer_instanceCounts: instanceCounts=0 debugee.stdout> MY_TRACE: debugLoop: Command set 1, command 21 debugee.stdout> MY_TRACE: debugLoop: Command set 1, command 21 - Done! MY_TRACE: TestDebuggerType2.quiteDebugge(): sending COMMAND_QUIT debugee.stderr> Debuggee: received the command: quit debugee.stdout> debugee.stdout> MY_TRACE: AbstractDebuggeeTest.doTest: COMMAND_QUIT debugee.stderr> Debuggee: exiting MY_TRACE: TestDebuggerType2.quiteDebugge(): got debuggee confirmation on COMMAND_QUIT Debuggee's process finished with status: 95 TEST PASSED This is a tail of tracing in the bad case (regression): debugee.stdout> MY_TRACE: HeapwalkingDebuggee.parseCommand: after DELETE_INSTANCES debugee.stdout> MY_TRACE: debugLoop: Command set 1, command 21 MY_TRACE: checkDebugeeAnswer_instanceCounts: instanceCounts=0 debugee.stdout> MY_TRACE: debugLoop: Command set 1, command 21 - Done! debugee.stdout> MY_TRACE: debugLoop: Command set 1, command 21 debugee.stdout> MY_TRACE: debugLoop: Command set 1, command 21 - Done! MY_TRACE: TestDebuggerType2.quiteDebugge(): sending COMMAND_QUIT debugee.stderr> Debuggee: received the command: quit debugee.stdout> debugee.stderr> Debuggee: exiting debugee.stdout> MY_TRACE: AbstractDebuggeeTest.doTest: COMMAND_QUIT debugee.stdout> MY_TRACE: debugLoop: Command set 1, command 2 debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] debugee.stderr> JDWP exit error JVMTI_ERROR_INVALID_ENVIRONMENT(116): Can't allocate jvmti memory [util.c:1797] debugee.stderr> ERROR: JDWP unable to dispose of JVMTI environment: JVMTI_ERROR_INVALID_ENVIRONMENT(116) debugee.stdout> # To suppress the following error report, specify this argument debugee.stdout> # after -XX: or in .hotspotrc: SuppressErrorAt=/os.cpp:613 debugee.stdout> Current thread is 17 debugee.stdout> Dumping core ... MY_TRACE: TestDebuggerType2.quiteDebugge(): got debuggee confirmation on COMMAND_QUIT # ERROR: TEST FAILED: debuggee's process finished with status: 6 TEST FAILED The JDWP command ClassesBySignature (2) is executed by the debugLoop_run after the debugger sent the debuggee COMMAND_QUIT looks weird: debugee.stdout> MY_TRACE: AbstractDebuggeeTest.doTest: COMMAND_QUIT debugee.stdout> MY_TRACE: debugLoop: Command set 1, command 2
23-09-2013
2013.09.19 RT_Baseline nightly: nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] debugee.stderr> JDWP exit error JVMTI_ERROR_INVALID_ENVIRONMENT(116): Can't allocate jvmti memory [util.c:1797] debugee.stderr> ERROR: JDWP unable to dispose of JVMTI environment: JVMTI_ERROR_INVALID_ENVIRONMENT(116) debugee.stdout> FATAL ERROR in native method: JDWP on getting class status, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112) debugee.stdout> # debugee.stdout> # A fatal error has been detected by the Java Runtime Environment: debugee.stdout> # debugee.stdout> # SIGSEGV (0xb) at pc=0xfffffff8530e6f18, pid=4594, tid=51 debugee.stdout> # debugee.stdout> # JRE version: Java(TM) SE Runtime Environment (8.0-b107) (build 1.8.0-ea-fastdebug-b107) debugee.stdout> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b50-internal-201309191508.hseigel.bug_8024517-fastdebug mixed mode solaris-sparc compressed oops) Test run URL:http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=292329.JAVASE.NIGHTLY.VM.RT_Baseline.2013-09-19-256 Host: slcaf320, Sun Sparcv9 2848 MHz, 64 cores, 128G, Solaris / Solaris 11, sun4v Options: -d64 -server -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:NativeMemoryTracking=detail -XX:ReservedCodeCacheSize=256M RULE nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 ExitCode 97 Crash Internal Error
20-09-2013
I wonder if this can have the same cause as JDK-8024985. The early init of methodhandle code causes methods in jdk.internal.org.objectweb.asm to be called. Perhaps there is a missing filter for these classes somewhere in the nsk/jdi code?
20-09-2013
Reply to David: The memory stomp is a secondary side-effect of Java class initialization. The first is that the JDWP agent gets out of sync with the debugger as in the log below: debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestInterfaceImplementer1:500 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: quit debugee.stderr> Debuggee: exiting debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] debugee.stderr> JDWP exit error JVMTI_ERROR_INVALID_ENVIRONMENT(116): Can't allocate jvmti memory [util.c:1797] debugee.stderr> ERROR: JDWP unable to dispose of JVMTI environment: JVMTI_ERROR_INVALID_ENVIRONMENT(116) debugee.stdout> FATAL ERROR in native method: JDWP on getting class status, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112) debugee.stdout> ## nof_mallocs = 153666, nof_frees = 140688 debugee.stdout> ## memory stomp: byte at 0x0806f230 in front of object 0x0806f248 debugee.stdout> ### previous object (not sure if correct): 0x0806f180 (64 bytes) debugee.stdout> ### next object: 0x0806f290 (8 bytes) debugee.stdout> # To suppress the following error report, specify this argument debugee.stdout> # after -XX: or in .hotspotrc: SuppressErrorAt=/os.cpp:613 debugee.stdout> Current thread is 17 debugee.stdout> Dumping core ... # ERROR: TEST FAILED: debuggee's process finished with status: 6 TEST FAILED It is caused by this class initialization: initialize_class(vmSymbols::java_lang_invoke_MethodHandleNatives(), CHECK_0);
20-09-2013
2013.09.18 RT_Baseline nightly: closed/compiler/6507107/HeapwalkingTest.java debuggee err>>>JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] debuggee out>>>FATAL ERROR in native method: JDWP on getting class status, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112) Test run URL: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=291803.JAVASE.NIGHTLY.VM.RT_Baseline.2013-09-18-14 Host: vmsqe-core2q-03, Intel Core(TM)2 Quad CPU @ 2.40GHz 2393 MHz, 4 cores, 4G, Linux / Ubuntu 11.04, x86_64 Options: -server -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M
19-09-2013
I always warn that initialization order changes tend to have unexpected side-effects but I am surprised by this - not sure how Java class initialization can lead to this memory stomp and a sigbus. I guess there is native code involved somewhere. Can we try adding back the initialization actions one at a time to see if it can be narrowed down.
19-09-2013
When the thread.cpp patch is disabled the test is passed on solaris-i586 in 1000 runs.
18-09-2013
The job 2013-08-26-205357.vlivanov.jsr292 lists 3 changesets: Changeset: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e47de6dfec5d Changeset: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/74608df95ba3 Changeset: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/022415fe638e Undoing the following update seems to fix the problem (a bigger test run is still in progress): --- a/src/share/vm/runtime/thread.cpp Mon Aug 26 17:37:25 2013 +0400 +++ b/src/share/vm/runtime/thread.cpp Mon Aug 26 17:41:05 2013 +0400 @@ -3636,6 +3636,16 @@ jint Threads::create_vm(JavaVMInitArgs* CompileBroker::compilation_init(); #endif + if (EnableInvokeDynamic) { + // Pre-initialize some JSR292 core classes to avoid deadlock during class loading. + // It is done after compilers are initialized, because otherwise compilations of + // signature polymorphic MH intrinsics can be missed + // (see SystemDictionary::find_method_handle_intrinsic). + initialize_class(vmSymbols::java_lang_invoke_MethodHandle(), CHECK_0); + initialize_class(vmSymbols::java_lang_invoke_MemberName(), CHECK_0); + initialize_class(vmSymbols::java_lang_invoke_MethodHandleNatives(), CHECK_0); + } + #if INCLUDE_MANAGEMENT Management::initialize(THREAD); #endif // INCLUDE_MANAGEMENT In fact, I don't understand yet the impact of the above pre-initialization.
18-09-2013
2013.09.17 RT_Baseline nightly: nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xffffffff7d6e7000, pid=14140, tid=51 # # JRE version: Java(TM) SE Runtime Environment (8.0-b107) (build 1.8.0-ea-fastdebug-b107) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b50-internal-201309171823.ctornqvi.hs-rt3-fastdebug mixed mode solaris-sparc compressed oops) # Problematic frame: # V [libjvm.so+0xee7000]Current thread is 53 Test run URL: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=291221.JAVASE.NIGHTLY.VM.RT_Baseline.2013-09-17-256 Host: slcaf650, Sun Sparcv9 2848 MHz, 64 cores, 128G, Solaris / Solaris 10, sun4v Options: -d64 -server -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:NativeMemoryTracking=detail -XX:ReservedCodeCacheSize=256M
18-09-2013
I've isolated the hotspot-comp integration: http://prt-web.us.oracle.com/archive/integrations/hsx/hotspot-comp/hotspot/2013-08-26-205357.vlivanov.jsr292/ I will double check that this result is correct.
18-09-2013
It seems, this regression came to the hotspot-main from the comp-to-main merge: 2013-09-05-090608.adlertz.comp_to_main Previous integration, the rt-to-main merge, does not fail: 2013-09-04-182332.zhgu.hotspot-rt-to-main
18-09-2013
The test instancecounts002 fails on solaris-i586 pretty quickly in several runs.
17-09-2013
Agreed. The JPRT archive for me is really slooow now. It takes 20+ minutes to download just one bundle.
17-09-2013
instancecounts002 is the test that caught my eye because it had more failures than the rest of the tests. On Monday, I saw instancecounts002 failures in RT_Baseline, Main_Baseline and my own AdHoc job were I had just resynced with RT_Baseline. This started in the HSX-25-B49 snapshot job so I would look at the JPRT pushes from the sub-baselines into Main_Baseline.
17-09-2013
Dan, thank you for a remainder about several failing tests. I had this in mind to check other tests as well. Do you think, those other failures can be better reproducible?
17-09-2013
The JDK promoted build b106 does not fail in 1000 runs: % /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b106/binaries/solaris-sparcv9/fastdebug/bin/java -version java version "1.8.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b106) Java HotSpot(TM) Server VM (build 25.0-b48-fastdebug, mixed mode) The previous HS snapshot 2013-08-30-072135.amurillo.hs25-b48-snapshot does not fail in 1000 runs: % /net/sc11152541/export/home/sspitsyn/hs25/hsx/solaris-sparcv9/fastdebug/bin/java -version java version "1.8.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b104) Java HotSpot(TM) Server VM (build 25.0-b46-fastdebug, mixed mode) Next step is to detect if it comes from the HotSpot integrations. One complication with this detection is that 1000 runs takes several hours to complete but even that is not enough to be sure.
17-09-2013
updated rules so failure is matched RULE nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 Crash Internal Error ...os.cpp...fatal error: memory stomping error RULE nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 ExitCode 97
17-09-2013
Please note that I logged this JVMTI_ERROR_WRONG_PHASE issue with several tests.
17-09-2013
There are 3 threads involved into this test communication: - Debugger (instancecounts001/HeapwalkingDebugger/TestDebuggerType2) . We do not have a stack trace for it (it is in the different process), but it has already sent the AbstractDebuggeeTest.COMMAND_QUIT command to the Debuggee. - Debuggee (HeapwalkingDebuggee/AbstractJDIDebuggee/AbstractDebuggeeTest) - Thread #2. It received the COMMAND_QUIT and in the process of shutdown. - The JDWP backend - debugLoop_run() - Thread #7. It is executing the JDWP command ClassesBySignature which is mapped to the function classesForSignature that is seen on the stack. It calls the classStatus() which get the jvmtiError=JVMTI_ERROR_WRONG_PHASE(112). It seems the debugLoop_run is out of sync with the Debugger and Debuggee. It is not clear yet why this happened. It can be a test fault, the JDWP backend fault and less likely the JVMTI fault. The key to this puzzle is if it is a regression or not.
17-09-2013
The following JDK promoted build b106 did not fail in 1000 runs: /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b106/binaries/solaris-sparcv9/fastdebug
17-09-2013
Finally, I was able to reproduce the bug with the b106/hs25-b48 on the 772-nd run: sspitsyn@sc11152541 cat 772 binder> VirtualMachineManager: version 1.6 binder> Finding connector: default binder> LaunchingConnector: binder> name: com.sun.jdi.CommandLineLaunch binder> description: Launches target using Sun Java VM command line and attaches to it binder> transport: com.sun.tools.jdi.SunCommandLineLauncher$2@3a71f4dd binder> Connector arguments: binder> home=/net/sc11152541/export/home/sspitsyn/hs25/hsx/solaris-sparcv9/fastdebug/jre binder> vmexec=java binder> options=-Xmx128M -d64 -server -server binder> main=nsk.share.jdi.HeapwalkingDebuggee "-verbose" "-arch=solaris-sparcv9" "-waittime=5" "-debugee.vmkind=java" "-transport.address=dynamic" "-debugee.vmkeys=-Xmx128M -d64 -server -server" "-pipe.port=40987" binder> quote=" binder> suspend=true binder> Launching debugee binder> Waiting for VM initialized Initial VMStartEvent received: VMStartEvent in thread main debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: createInstances:nsk.share.jdi.TestClass1:2 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: createInstances:nsk.share.jdi.TestClass2:20 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: createInstances:nsk.share.jdi.TestInterfaceImplementer1:1000 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestClass1:1 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestClass2:10 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestInterfaceImplementer1:500 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: forceGC debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestClass1:1 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestClass2:10 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestInterfaceImplementer1:500 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: quit debugee.stderr> Debuggee: exiting debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] debugee.stdout> FATAL ERROR in native method: JDWP on getting class status, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112) debugee.stdout> Current thread is 7 debugee.stdout> Dumping core ... # ERROR: TEST FAILED: debuggee's process finished with status: 6 TEST FAILED #> #> SUMMARY: Following errors occured #> during test execution: #> # ERROR: TEST FAILED: debuggee's process finished with status: 6 sspitsyn@sc11152541 /net/sc11152541/export/home/sspitsyn/hs25/hsx/solaris-sparcv9/fastdebug/bin/java -version java version "1.8.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b106) Java HotSpot(TM) Server VM (build 25.0-b48-fastdebug, mixed mode) I've unpacked the solaris-sparcv9 fastdebug bundle from the following JPRT integration: http://prt-web.us.oracle.com/archive/integrations/hsx/hsx25/hotspot/2013-09-06-180541.jcoomes.hs25-b49-snapshot/bundles/
17-09-2013
Not reproducible with b106/hs25-b48 in multiple hundred runs.
17-09-2013
This looks like a test issue as the debugee already received the command 'quit', and so, is exiting: debugee.stderr> Debuggee: received the command: quit debugee.stderr> Debuggee: exiting But need to check if it is really a regression first.
16-09-2013
This is a pstack dump of the core file: core 'core' of 19783: /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b107/binaries/sol ----------------- lwp# 1 / thread# 1 -------------------- ff08e6ec __lwp_wait (2, ffbfd4ec, 0, ff087724, 1, 0) + 8 ff0875c8 _thrp_join (2, 0, ffbfd5b0, 1, ffbfd4ec, ff107940) + 34 ff087734 thr_join (2, 0, ffbfd5b0, ffbfd624, 0, 0) + 10 ff14b35c ContinueInNewThread0 (ff145778, 0, 80000, ffbfd624, 80000, 200) + 30 ff148ec8 ContinueInNewThread (ffbfd778, fddf4508, ff1639fc, fddf3de0, fddf3ff4, ffbfe724) + bc ff14b3dc JVMInit (ffbfd778, 0, ffbfe724, 7, 2156c, 1) + 40 ff145768 JLI_Launch (0, 3bc, fffee6f0, 0, 1, 0) + 29c 00010e4c main (e, ffbfe474, 0, 10eb8, 200, 0) + b8 00010964 _start (0, 0, 0, 0, 0, 0) + 108 ----------------- lwp# 2 / thread# 2 -------------------- fdc570a4 void InstanceKlass::methods_do(void()(Method)) (ea085008, fdcfd550, 5c, fe838000, 20, ea083ba0) + 70 fdaeab0c void Dictionary::methods_do(void()(Method)) (e8b00, fdcfd550, 149c50, 1, fecddb68, ea085008) + 1b0 fe3bfd08 void SystemDictionary::methods_do(void()(Method)) (fdcfd550, f68c00, fed1af70, fec6636c, b4c04, b4c00) + 38 fdcfe2bc void print_method_profiling_data() (2eed8, 2eed8, 400, fec6636c, fe87a55c, fed4b864) + 180 fdcfe804 void print_statistics() (fec9f527, 0, 1, 391bb, fed49074, 39000) + 31c fdcff2ac void before_exit(JavaThread) (2e800, 69de6, 4fc, fe87a36a, fec6636c, 698eb) + 594 fde3a038 JVM_Halt (5f, 69800, 2e800, fec6636c, 2f2f8, 4) + 24c fd10235c Java_java_lang_Shutdown_halt0 (2e95c, fd1ff848, 5f, 20000000, 0, 0) + 4 f2c20204 java/lang/Shutdown.halt0(I)V+0 f2c200e0 * java/lang/Shutdown.halt0(I)V+0 f2c06770 * java/lang/Shutdown.halt(I)V+7 f2c06770 * java/lang/Shutdown.exit(I)V+99 f2c06770 * java/lang/Runtime.exit(I)V+14 f2c06770 * java/lang/System.exit(I)V+4 f2c06770 * nsk/share/jpda/AbstractDebuggeeTest.doTest()V+210 f2c06770 * nsk/share/jdi/HeapwalkingDebuggee.main([Ljava/lang/String;)V+14 f2c002e8 * StubRoutines (1) fdd06e10 void JavaCalls::call_helper(JavaValue,methodHandle,JavaCallArguments,Thread) (fd1ffef0, f2c00260, ea28c110, 2e800, f2c18220, fd1ffca4) + 73c fdd95600 void jni_invoke_static(JNIEnv_,JavaValue,_jobject,JNICallType,_jmethodID,JNI_ArgumentPusher,Thread) (2e95c, fd1ffef0, 2, 2e800, 3c, 4) + 98c fddbf800 jni_CallStaticVoidMethod (2e95c, fffffff2, 335f3c, 63, 2e800, fece9aa0) + 560 ff145d00 JavaMain (2ffd4, fddf4508, ff152168, 2156c, 7, 0) + 588 ff08a9c8 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- ff08e7c0 _lwp_cond_signal (128024, 128000, ffd84fba, 0, fea384d6, fec6636c) + 8 fe4e447c void VMThread::loop() (fecff0b8, 176950, fed349c8, 6a000, 69800, fed34b20) + fb4 fe4e2ab8 void VMThread::run() (175c00, fecff128, fecd03e0, 98c00, fec6636c, febdd918) + d8 fe1d2e58 java_start (175c00, 2, 176b38, 233800, fec6636c, fea32996) + 16c ff08a9c8 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 4 / thread# 4 -------------------- ff08e7a0 ___lwp_cond_wait (17b550, 17b538, ffdd1b0e, 22e400, 360, 13bda8) + 8 fe1e29f0 void os::PlatformEvent::park() (17b500, fed49778, 98c00, e3400, 17b550, 0) + 140 fe1af674 void ObjectMonitor::wait(long long,bool,Thread) (196f10, fed1cfc0, 196f64, fea1fcf0, 1, 17a800) + 3b8 fe3b1854 void ObjectSynchronizer::wait(Handle,long long,Thread) (f2a1f474, f2a1f3c4, f0b8e880, 17a800, 196f10, 196f12) + 450 fde3d558 JVM_MonitorWait (f2a1f438, 17bc4c, 17bc2c, fec6636c, 17a800, f2a1f438) + 6ec f2c20204 * java/lang/Object.wait(J)V+8592 f2c200e0 * java/lang/Object.wait(J)V+0 f2c06770 * java/lang/Object.wait()V+2 f2c06770 * java/lang/ref/Reference$ReferenceHandler.run()V+36 f2c002e8 * StubRoutines (1) fdd06e10 void JavaCalls::call_helper(JavaValue,methodHandle,JavaCallArguments,Thread) (f2a1fa60, f2c00260, ea0ad4f8, 17a800, f2c18220, f2a1f7dc) + 73c fdd05930 void JavaCalls::call_virtual(JavaValue,KlassHandle,Symbol,Symbol,JavaCallArguments,Thread) (f2a1fa60, f2a1f998, 669e0, 67dd0, f2a1f9a4, 17a800) + 21c fdd05a40 void JavaCalls::call_virtual(JavaValue,Handle,KlassHandle,Symbol,Symbol,Thread) (f2a1fa60, f2a1fa5c, ea02ea40, 669e0, 67dd0, 17a800) + cc fde6f31c void thread_entry(JavaThread,Thread) (ea02ea40, e3ba4, 69dea, ea8056a8, fed49f10, f2a1fa74) + f4 fe40a15c void JavaThread::thread_main_inner() (17a800, f2a1fb24, 17ad40, fec6636c, fecd0156, 17a944) + 274 fe409e6c void JavaThread::run() (17a800, 69c00, 1, fec6636c, 17a944, 127c00) + 43c fe1d2e58 java_start (17a800, 2, 17be20, 233800, fec6636c, fea32996) + 16c ff08a9c8 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 5 / thread# 5 -------------------- ff08e7a0 ___lwp_cond_wait (17d050, 17d038, ffdd1b0e, 22e400, 370, 13bda8) + 8 fe1e29f0 void os::PlatformEvent::park() (17d000, fed49778, 98c00, e3400, 17d050, 0) + 140 fe1af674 void ObjectMonitor::wait(long long,bool,Thread) (197d10, fed1cfc0, 197d64, fea1fcf0, 1, 17c000) + 3b8 fe3b1854 void ObjectSynchronizer::wait(Handle,long long,Thread) (f298f464, f298f3b4, ebb31a48, 17c000, 197d10, 197d12) + 450 fde3d558 JVM_MonitorWait (f298f428, 17d6ac, 17d68c, fec6636c, 17c000, f298f428) + 6ec f2c20204 java/lang/Object.wait(J)V+-17616 f2c200e0 * java/lang/Object.wait(J)V+0 f2c06770 * java/lang/ref/ReferenceQueue.remove(J)Ljava/lang/ref/Reference;+44 f2c069f0 * java/lang/ref/ReferenceQueue.remove()Ljava/lang/ref/Reference;+2 f2c069f0 * java/lang/ref/Finalizer$FinalizerThread.run()V+16 f2c002e8 * StubRoutines (1) fdd06e10 void JavaCalls::call_helper(JavaValue,methodHandle,JavaCallArguments,Thread) (f298fae0, f2c00260, ea0af370, 17c000, f2c18220, f298f85c) + 73c fdd05930 void JavaCalls::call_virtual(JavaValue,KlassHandle,Symbol,Symbol,JavaCallArguments,Thread) (f298fae0, f298fa18, 669e0, 67dd0, f298fa24, 17c000) + 21c fdd05a40 void JavaCalls::call_virtual(JavaValue,Handle,KlassHandle,Symbol,Symbol,Thread) (f298fae0, f298fadc, ea02ea40, 669e0, 67dd0, 17c000) + cc fde6f31c void thread_entry(JavaThread,Thread) (ea02ea40, e3ba4, 69dea, ea805bc8, fed49f10, f298faf4) + f4 fe40a15c void JavaThread::thread_main_inner() (17c000, f298fba4, 17c780, fec6636c, fecd0156, 17c144) + 274 fe409e6c void JavaThread::run() (17c000, 69c00, 1, fec6636c, 17c144, 127c00) + 43c fe1d2e58 java_start (17c000, 2, 17d880, 233800, fec6636c, fea32996) + 16c ff08a9c8 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 7 / thread# 7 -------------------- ff08e6bc _lwp_kill (6, 0, ff107100, ff06dc48, ffffffff, 6) + 8 ff002950 abort (ea7ef470, 1, fe1eb37c, ffba0, ff105518, 0) + 110 fe1d5280 void os::abort(bool) (fe1eb360, ffdcd2ae, 232c00, fed063e4, ea7ef470, fed063e4) + 14c fdd91fec jni_FatalError (1bd55c, e2d08, 1c44c8, 1bd400, 82b50, fec6636c) + 3cc fd0b17f0 jniFatalError (fffeac6c, fd0d725c, 70, 1, 15000, fd0e75dc) + f4 fd0b2fe8 debugInit_exit (70, fd0d725c, 1, fd0e7b38, 1, fd0e7b38) + f0 fd0cd1fc classStatus (fd0d6848, 0, ff10758c, fd0e7b38, fd0d725c, 70) + d4 fd0abe3c classesForSignature (ea7efac0, ea7ef960, 1ad850, fd0e75dc, 1bd55c, 6a8) + dc fd0b3304 debugLoop_run (400, fd0e7ac0, fd0abd60, fd0e75dc, ea7efae0, ea7efac0) + 1b4 fd0c855c connectionInitiated (f2873020, 0, fd0e75dc, 1, 9d8, fd0e7fb4) + f4 fd0c8824 attachThread (400, fd0e75dc, f2873020, fd0d6764, fffef188, 10c00) + 58 fdf89d44 void JvmtiAgentThread::call_start_function() (1ffc, 6, fed03254, 28bd8, 0, 0) + 208 fe40a15c void JavaThread::thread_main_inner() (1bd400, ea7efca4, 1bd878, fec6636c, fecd0156, 1bd544) + 274 fe409e6c void JavaThread::run() (1bd400, 69c00, 1, fec6636c, 1bd544, 127c00) + 43c fe1d2e58 java_start (1bd400, 2, 1be5d8, 233800, fec6636c, fea32996) + 16c ff08a9c8 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 8 / thread# 8 -------------------- ff08e7a0 ___lwp_cond_wait (1c1050, 1c1038, ffdd1b0e, 22e400, 698d4, 13bda8) + 8 fe1e29f0 void os::PlatformEvent::park() (1c1000, fed49778, ffffffff, e3400, 1c1050, 0) + 140 fdf93000 int JvmtiRawMonitor::SimpleWait(Thread,long long) (1bfc98, 1c0000, ffffffff, ffcd2aa7, fe938e13, 0) + 124 fdf93944 int JvmtiRawMonitor::raw_wait(long long,bool,Thread) (1c0000, ffffffff, ffffffff, 1bfcec, 1c0000, 1bfc98) + 110 fdf57b20 jvmtiError JvmtiEnv::RawMonitorWait(JvmtiRawMonitor,long long) (1c0000, 1bfc98, ffffffff, 4, fec6636c, fe91e2ae) + f0 fd0cc8f4 debugMonitorWait (fd0e7b38, fd0e7b38, fd0e7ac0, fd0e75dc, 4e4, 400) + 44 fd0bb52c dequeueCommand (3ee588, fffed814, 12400, fd0e75dc, fd0e7d08, fd0e7d0c) + 60 fd0bc534 commandLoop (fd0e7b38, 1c015c, fd0e75dc, fd0e7ac0, 4e4, 400) + 5c fdf89d44 void JvmtiAgentThread::call_start_function() (1ffc, 6, fed03254, 28bd8, 0, 0) + 208 fe40a15c void JavaThread::thread_main_inner() (1c0000, ea75fda4, 1c07d0, fec6636c, fecd0156, 1c0144) + 274 fe409e6c void JavaThread::run() (1c0000, 69c00, 1, fec6636c, 1c0144, 127c00) + 43c fe1d2e58 java_start (1c0000, 2, 1c18b0, 233800, fec6636c, fea32996) + 16c ff08a9c8 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 10 / thread# 10 -------------------- ff08e7a0 ___lwp_cond_wait (1cac50, 1cac38, ffdd1b0e, 22e400, ff08ea90, 13bda8) + 8 fe1e29f0 void os::PlatformEvent::park() (1cac00, fed49778, 0, e3400, 1cac50, 0) + 140 fe1642b8 int Monitor::IWait(Thread,long long) (2ddf8, 1c9800, ffd849a1, feccfcf8, ffffffff, 2de0c) + fc fe1659dc bool Monitor::wait(bool,long,bool) (2ddf8, 1c9800, 0, fed03258, fe9ebc1b, fec6636c) + 534 fda03cd8 CompileTaskCompileQueue::get() (51400, 216f8, 1c91e0, fec6636c, ea63fc90, feca3420) + 174 fda06dcc void CompileBroker::compiler_thread_loop() (a000000, 216f8, fec6636c, 1c91e0, 1c9800, fecb7c7c) + 28c fe40a15c void JavaThread::thread_main_inner() (1c9800, ea63fe24, 1ca020, fec6636c, fecd0156, 1c9944) + 274 fe409e6c void JavaThread::run() (1c9800, 69c00, 1, fec6636c, 1c9944, 127c00) + 43c fe1d2e58 java_start (1c9800, 2, 1cb110, 233800, fec6636c, fea32996) + 16c ff08a9c8 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 11 / thread# 11 -------------------- ff08e7a0 ___lwp_cond_wait (1ccf50, 1ccf38, ffdd1b0e, 22e400, 0, 13bda8) + 8 fe1e29f0 void os::PlatformEvent::park() (1ccf00, fed49778, 0, e3400, 1ccf50, 0) + 140 fe1642b8 int Monitor::IWait(Thread,long long) (2ddf8, 1cc000, ffd849a1, feccfcf8, ffffffff, 2de0c) + fc fe1659dc bool Monitor::wait(bool,long,bool) (2ddf8, 1cc000, 0, fed03258, fe9ebc1b, fec6636c) + 534 fda03cd8 CompileTaskCompileQueue::get() (51400, 216f8, 1c9228, fec6636c, ea5af910, feca3420) + 174 fda06dcc void CompileBroker::compiler_thread_loop() (a000000, 216f8, fec6636c, 1c9228, 1cc000, fecb7c7c) + 28c fe40a15c void JavaThread::thread_main_inner() (1cc000, ea5afaa4, 1cb7e8, fec6636c, fecd0156, 1cc144) + 274 fe409e6c void JavaThread::run() (1cc000, 69c00, 1, fec6636c, 1cc144, 127c00) + 43c fe1d2e58 java_start (1cc000, 2, 1cd498, 233800, fec6636c, fea32996) + 16c ff08a9c8 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 12 / thread# 12 -------------------- ff08e7a0 ___lwp_cond_wait (265350, 265338, ffdd1b0e, 22e400, 0, 13bda8) + 8 fe1e29f0 void os::PlatformEvent::park() (265300, fed49778, 0, e3400, 265350, 0) + 140 fe1642b8 int Monitor::IWait(Thread,long long) (2c1c0, 264c00, ffd849a1, feccfcf8, ffffffff, 2c1d4) + fc fe165650 bool Monitor::wait(bool,long,bool) (2c1c0, 264c00, 0, 0, fe9ebc1b, fec6636c) + 1a8 fe2fc260 void ServiceThread::service_thread_entry(JavaThread,Thread) (264c00, 264c00, 0, 0, 0, 0) + 2b4 fe40a15c void JavaThread::thread_main_inner() (264c00, ea51fb24, 1e8880, fec6636c, fecd0156, 264d44) + 274 fe409e6c void JavaThread::run() (264c00, 69c00, 1, fec6636c, 264d44, 127c00) + 43c fe1d2e58 java_start (264c00, 2, 2627d0, 233800, fec6636c, fea32996) + 16c ff08a9c8 _lwp_start (0, 0, 0, 0, 0, 0) From the stack traces we can see that the debugee is at shut down: ----------------- lwp# 2 / thread# 2 -------------------- fdc570a4 void InstanceKlass::methods_do(void()(Method)) (ea085008, fdcfd550, 5c, fe838000, 20, ea083ba0) + 70 fdaeab0c void Dictionary::methods_do(void()(Method)) (e8b00, fdcfd550, 149c50, 1, fecddb68, ea085008) + 1b0 fe3bfd08 void SystemDictionary::methods_do(void()(Method)) (fdcfd550, f68c00, fed1af70, fec6636c, b4c04, b4c00) + 38 fdcfe2bc void print_method_profiling_data() (2eed8, 2eed8, 400, fec6636c, fe87a55c, fed4b864) + 180 fdcfe804 void print_statistics() (fec9f527, 0, 1, 391bb, fed49074, 39000) + 31c fdcff2ac void before_exit(JavaThread) (2e800, 69de6, 4fc, fe87a36a, fec6636c, 698eb) + 594 fde3a038 JVM_Halt (5f, 69800, 2e800, fec6636c, 2f2f8, 4) + 24c fd10235c Java_java_lang_Shutdown_halt0 (2e95c, fd1ff848, 5f, 20000000, 0, 0) + 4 f2c20204 * java/lang/Shutdown.halt0(I)V+0 f2c200e0 * java/lang/Shutdown.halt0(I)V+0 f2c06770 * java/lang/Shutdown.halt(I)V+7 f2c06770 * java/lang/Shutdown.exit(I)V+99 f2c06770 * java/lang/Runtime.exit(I)V+14 f2c06770 * java/lang/System.exit(I)V+4 f2c06770 * nsk/share/jpda/AbstractDebuggeeTest.doTest()V+210 f2c06770 * nsk/share/jdi/HeapwalkingDebuggee.main([Ljava/lang/String;)V+14 f2c002e8 * StubRoutines (1) fdd06e10 void JavaCalls::call_helper(JavaValue,methodHandle,JavaCallArguments,Thread) (fd1ffef0, f2c00260, ea28c110, 2e800, f2c18220, fd1ffca4) + 73c fdd95600 void jni_invoke_static(JNIEnv_,JavaValue,_jobject,JNICallType,_jmethodID,JNI_ArgumentPusher,Thread) (2e95c, fd1ffef0, 2, 2e800, 3c, 4) + 98c fddbf800 jni_CallStaticVoidMethod (2e95c, fffffff2, 335f3c, 63, 2e800, fece9aa0) + 560 ff145d00 JavaMain (2ffd4, fddf4508, ff152168, 2156c, 7, 0) + 588 ff08a9c8 _lwp_start (0, 0, 0, 0, 0, 0) This is a reason why we got the jvmtiError=JVMTI_ERROR_WRONG_PHASE(112). I have no idea yet what actually happened. Most likely, it is just normal ending as it has been completed. I'll check if this is reproducible with the build b106. This is the debug loop thread stack trace: ----------------- lwp# 7 / thread# 7 -------------------- ff08e6bc _lwp_kill (6, 0, ff107100, ff06dc48, ffffffff, 6) + 8 ff002950 abort (ea7ef470, 1, fe1eb37c, ffba0, ff105518, 0) + 110 fe1d5280 void os::abort(bool) (fe1eb360, ffdcd2ae, 232c00, fed063e4, ea7ef470, fed063e4) + 14c fdd91fec jni_FatalError (1bd55c, e2d08, 1c44c8, 1bd400, 82b50, fec6636c) + 3cc fd0b17f0 jniFatalError (fffeac6c, fd0d725c, 70, 1, 15000, fd0e75dc) + f4 fd0b2fe8 debugInit_exit (70, fd0d725c, 1, fd0e7b38, 1, fd0e7b38) + f0 fd0cd1fc classStatus (fd0d6848, 0, ff10758c, fd0e7b38, fd0d725c, 70) + d4 fd0abe3c classesForSignature (ea7efac0, ea7ef960, 1ad850, fd0e75dc, 1bd55c, 6a8) + dc fd0b3304 debugLoop_run (400, fd0e7ac0, fd0abd60, fd0e75dc, ea7efae0, ea7efac0) + 1b4 fd0c855c connectionInitiated (f2873020, 0, fd0e75dc, 1, 9d8, fd0e7fb4) + f4 fd0c8824 attachThread (400, fd0e75dc, f2873020, fd0d6764, fffef188, 10c00) + 58 fdf89d44 void JvmtiAgentThread::call_start_function() (1ffc, 6, fed03254, 28bd8, 0, 0) + 208 fe40a15c void JavaThread::thread_main_inner() (1bd400, ea7efca4, 1bd878, fec6636c, fecd0156, 1bd544) + 274 fe409e6c void JavaThread::run() (1bd400, 69c00, 1, fec6636c, 1bd544, 127c00) + 43c fe1d2e58 java_start (1bd400, 2, 1be5d8, 233800, fec6636c, fea32996) + 16c ff08a9c8 _lwp_start (0, 0, 0, 0, 0, 0)
16-09-2013
I was able to reproduce it on solaris-sparc with the jdk promoted build b107 in 100 runs: binder> VirtualMachineManager: version 1.6 binder> Finding connector: default binder> LaunchingConnector: binder> name: com.sun.jdi.CommandLineLaunch binder> description: Launches target using Sun Java VM command line and attaches to it binder> transport: com.sun.tools.jdi.SunCommandLineLauncher$2@71f4dd binder> Connector arguments: binder> home=/net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b107/binaries/solaris-sparc/fastdebug/jre binder> vmexec=java binder> options=-Xmx128M -server -server binder> main=nsk.share.jdi.HeapwalkingDebuggee "-verbose" "-arch=solaris-sparc" "-waittime=5" "-debugee.vmkind=java" "-transport.address=dynamic" "-debugee.vmkeys=-Xmx128M -server -server" "-pipe.port=57435" binder> quote=" binder> suspend=true binder> Launching debugee binder> Waiting for VM initialized Initial VMStartEvent received: VMStartEvent in thread main debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: createInstances:nsk.share.jdi.TestClass1:2 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: createInstances:nsk.share.jdi.TestClass2:20 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: createInstances:nsk.share.jdi.TestInterfaceImplementer1:1000 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestClass1:1 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestClass2:10 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestInterfaceImplementer1:500 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: forceGC debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestClass1:1 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestClass2:10 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: deleteInstances:nsk.share.jdi.TestInterfaceImplementer1:500 debugee.stderr> Debuggee nsk.share.jdi.HeapwalkingDebuggee : sending the command: ready debugee.stderr> Debuggee: received the command: quit debugee.stderr> Debuggee: exiting debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] debugee.stdout> FATAL ERROR in native method: JDWP on getting class status, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112) debugee.stdout> Current thread is 7 debugee.stdout> Dumping core ... # ERROR: TEST FAILED: debuggee's process finished with status: 6 TEST FAILED
16-09-2013
The nsk/jdi instancecounts002 test is a scenario test that in fact executes instancecounts001 test. The instancecounts001.doTest() calls in the loop the HeapwalkingDebugger.checkDebugeeAnswer_instanceCounts(): //create instances for (int i = 0; i < testClassNames.length; i++) { pipe.println(HeapwalkingDebuggee.COMMAND_CREATE_INSTANCES + ":" + testClassNames[i] + ":" + testInstanceCount[i]); checkDebugeeAnswer_instanceCounts(testClassNames[i], testInstanceCount[i]); } But this function is silently returned if the Debugee is not ready: // check value returned by VirtualMachine.instanceCounts, // note that method call method isDebuggeeReady() which check that debuggee completed pervious command and is ready for new one public void checkDebugeeAnswer_instanceCounts(String className, int expectedValue) { if (!isDebuggeeReady()) return; The fact that the function can be silently returned is not checked at all. This can be a factor of tests instability, I think. The isDebuggeeReady is defined in the TestDebuggerType2 which is the super class of the HeapwalkingDebugger: // check the debuggee completed pervious command and is ready for new one protected boolean isDebuggeeReady() { String command = pipe.readln(); if (!command.equals(AbstractDebuggeeTest.COMMAND_READY)) { setSuccess(false); log.complain("TEST BUG: unknown debuggee's command: " + command); return false; } return true; } Should I file a test bug on this?
16-09-2013
There is another bug with the JVMTI_ERROR_WRONG_PHASE(112) error: https://bugs.openjdk.java.net/browse/JDK-6988950 But it was filed back in Oct of 2010. Probably, I saw more bugs with this error. I wonder if this one is a real regression. Then it would make sense to isolate the integration caused it.
16-09-2013
This failure was spotted in an AdHoc testing job in a different test,. The failure mode of getting a JVMTI_ERROR_WRONG_PHASE after the debuggee VM has finished is very similar. JDK: Java(TM) SE Runtime Environment 1.8.0 b106 (1.8.0-ea-b106) VM: Java HotSpot(TM) Client VM 25.0 b50 (25.0-b50-internal-201309132010.ddaugher.8019835_exp) nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001 This test failed due to: [2013-09-15T00:39:49.54] debugee.stderr> Debuggee nsk.share.jdi.AbstractJDIDebuggee : sending the command: ready [2013-09-15T00:39:49.86] Got expected exception: com.sun.jdi.VMOutOfMemoryException [2013-09-15T00:39:49.87] debugee.stderr> Debuggee: received the command: quit [2013-09-15T00:39:49.87] debugee.stderr> Debuggee: exiting [2013-09-15T00:39:49.87] debugee.stdout> FATAL ERROR in native method: JDWP on getting class status, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112) [2013-09-15T00:39:49.87] debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] [2013-09-15T00:39:49.89] # ERROR: TEST FAILED: debuggee's process finished with status: 1 [2013-09-15T00:39:49.89] TEST FAILED [2013-09-15T00:39:49.89] [2013-09-15T00:39:49.89] [2013-09-15T00:39:49.89] #> [2013-09-15T00:39:49.89] #> SUMMARY: Following errors occured [2013-09-15T00:39:49.89] #> during test execution: [2013-09-15T00:39:49.89] #> [2013-09-15T00:39:49.89] # ERROR: TEST FAILED: debuggee's process finished with status: 1 [2013-09-15T00:39:49.93] # Test level exit status: 97 I'm including the VMOutOfMemoryException part from the log file because Aurora detects it, but doesn't know that it is an expected exception.
16-09-2013
This failure was spotted in an AdHoc testing job in a different test,. The failure mode of getting a JVMTI_ERROR_WRONG_PHASE after the debuggee VM has finished is very similar. JDK: Java(TM) SE Runtime Environment 1.8.0 b106 (1.8.0-ea-b106) VM: Java HotSpot(TM) Client VM 25.0 b50 (25.0-b50-internal-201309132010.ddaugher.8019835_exp) nsk/jdi/ReferenceType/instances/instances005 This test failed due to the following: [2013-09-15T01:19:10.92] debugee.stderr> Debuggee: exiting [2013-09-15T01:19:10.92] debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] [2013-09-15T01:19:10.94] debugee.stdout> FATAL ERROR in native method: JDWP on getting class status, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112) [2013-09-15T01:19:11.73] # ERROR: TEST FAILED: debuggee's process finished with status: 134 [2013-09-15T01:19:11.73] TEST FAILED [2013-09-15T01:19:11.73] [2013-09-15T01:19:11.73] [2013-09-15T01:19:11.73] #> [2013-09-15T01:19:11.73] #> SUMMARY: Following errors occured [2013-09-15T01:19:11.73] #> during test execution: [2013-09-15T01:19:11.73] #> [2013-09-15T01:19:11.73] # ERROR: TEST FAILED: debuggee's process finished with status: 134 [2013-09-15T01:19:11.76] # Test level exit status: 97
16-09-2013
This failure was spotted in an AdHoc testing job in a different test,. The failure mode of getting a JVMTI_ERROR_WRONG_PHASE after the debuggee VM has finished is very similar. JDK: Java(TM) SE Runtime Environment 1.8.0 b106 (1.8.0-ea-b106) VM: Java HotSpot(TM) 64-Bit Server VM 25.0 b50 (25.0-b50-internal-201309132010.ddaugher.8019835_exp) nsk/jdi/ObjectReference/referringObjects/referringObjects003 This test failed due to the following: [2013-09-15T01:11:25.50] debugee.stderr> Debuggee: exiting [2013-09-15T01:11:25.50] debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] [2013-09-15T01:11:25.50] debugee.stdout> FATAL ERROR in native method: JDWP on getting class status, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112) [2013-09-15T01:11:42.05] # ERROR: TEST FAILED: debuggee's process finished with status: 6 [2013-09-15T01:11:42.05] TEST FAILED [2013-09-15T01:11:42.05] [2013-09-15T01:11:42.05] [2013-09-15T01:11:42.05] #> [2013-09-15T01:11:42.05] #> SUMMARY: Following errors occured [2013-09-15T01:11:42.05] #> during test execution: [2013-09-15T01:11:42.05] #> [2013-09-15T01:11:42.05] # ERROR: TEST FAILED: debuggee's process finished with status: 6 [2013-09-15T01:11:42.30] # Test level exit status: 97
16-09-2013
This failure was spotted in an AdHoc testing job in a different test,. The failure mode of getting a JVMTI_ERROR_WRONG_PHASE after the debuggee VM has finished is very similar. JDK: Java(TM) SE Runtime Environment 1.8.0 b106 (1.8.0-ea-b106) VM: Java HotSpot(TM) Client VM 25.0 b50 (25.0-b50-internal-201309132010.ddaugher.8019835_exp) nsk/jdi/ClassObjectReference/toString/tostring001 This test failed due to the following: [2013-09-15T01:05:31.13] debugee.stderr> debuggee > completed succesfully. [2013-09-15T01:05:31.13] debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface [util.c:1311] [2013-09-15T01:05:31.13] debugee.stdout> FATAL ERROR in native method: JDWP on checking for an interface, jvmtiError=JVMTI_ERROR_WRONG_PHASE(112) [2013-09-15T01:05:35.47] Exception in thread "main" nsk.share.Failure: Got unexpected debugee VM exit status: 6 (not 95) [2013-09-15T01:05:35.47] at nsk.share.jdi.Debugee.quit(Debugee.java:534) [2013-09-15T01:05:35.47] at nsk.jdi.ClassObjectReference.toString.tostring001.run(tostring001.java:96) [2013-09-15T01:05:35.47] at nsk.jdi.ClassObjectReference.toString.tostring001.main(tostring001.java:67) [2013-09-15T01:05:35.50] # Test level exit status: 1
16-09-2013
Another failure in the HSX-25-B49 PIT snapshot. nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 This test failed due to the following: [2013-09-07T00:55:20.11] debugee.stderr> Debuggee: exiting [2013-09-07T00:55:20.12] debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] [2013-09-07T00:55:20.12] debugee.stderr> JDWP exit error JVMTI_ERROR_INVALID_ENVIRONMENT(116): Can't allocate jvmti memory [util.c:1797] [2013-09-07T00:55:20.12] debugee.stderr> ERROR: JDWP unable to dispose of JVMTI environment: JVMTI_ERROR_INVALID_ENVIRONMENT(116) [2013-09-07T00:55:20.17] # ERROR: TEST FAILED: debuggee's process finished with status: 1 [2013-09-07T00:55:20.17] TEST FAILED
16-09-2013
Another failure in the HSX-25-B49 PIT snapshot. nsk/jdi/VirtualMachine/instanceCounts/instancecounts002 This test failed due to the following: [2013-09-07T01:18:34.83] debugee.stderr> Debuggee: exiting [2013-09-07T01:18:34.83] debugee.stderr> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting class status [util.c:1283] [2013-09-07T01:18:34.85] # ERROR: TEST FAILED: debuggee's process finished with status: 1 [2013-09-07T01:18:34.85] TEST FAILED
16-09-2013