JDK-6328518 : nsk/jvmti/scenarios/hotswap/HS101/hs101t004 fails intermittently with assertion
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-09-26
  • Updated: 2017-11-21
  • Resolved: 2005-11-02
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 6
6 b59Fixed
Related Reports
Relates :  
Relates :  
Description
The following test started failing intemittently with assertion:
  nsk/jvmti/scenarios/hotswap/HS101/hs101t004

It happens in fastdebug mode with client VM and -Xcomp on Solaris-x86.
The SQE machine tictoc.sfbay is the best machine to reproduce the bug.

This is from Dan's nightly analysis:

New nsk.jvmti failures (from 2005.09.22)
*   nsk/jvmti/scenarios/hotswap/HS101/hs101t004
        This test failed the following assert on Solaris X86 Client VM
        (machine tictoc):

            Internal Error (src/share/vm/ci/ciEnv.cpp, 717)
            Error: assert(counter_changed,"failed dependencies, but
                counter didn't change")

        The test failed the same way in the first run. I checked the
        2005.09.21 run for the same configuration and the test passed
        (machine kashyyyk). I also checked my archive and this test has
        failed before, but _not_ in the current mode.

        The 2005.09.22 run picked up 20050922110651.coleenp.rt_merge
        from main/baseline; that is the only change relative to the
        2005.09.21 run. rt_baseline runs nsk.jvmti.unit which does not
        include this test. I looked through Coleen's putback message,
        but nothing jumps out at me.



This is a .tlog below:

#!/usr/bin/sh

LD_LIBRARY_PATH=/net/vmsqe.sfbay/export/backup/UNIFIED-DTF/DTWS/suites/nsk.jvmti/testbase/bin/lib/intel/nsk/share/jvmti/hotswap:/net/vmsqe.sfbay/export/backup/UNIFIED-DTF/DTWS/suites/nsk.jvmti/testbase/src/nsk/share/lib/intel:/net/vmsqe.sfbay/export/nightly/mantis/JDK/service_hs_baseline/jdk1.6/solaris-i586/jre/lib/i386/client
RAS_OPTIONS=
SHELL=/usr/bin/sh
DISPLAY=vmsqe.sfbay:0.0
CLASSPATH=/var/tmp/fhsu/Work/exec/nsk.jvmti-NIGHTLY-Serv_Baseline-ClientVM-comp-solx86-2005-09-22-20-34-17/run2/fhsu.Solaris.x86/hs101t004:/net/vmsqe.sfbay/export/backup/UNIFIED-DTF/DTWS/suites/nsk.jvmti/testbase/bin/classes:/net/vmsqe.sfbay/export/nightly/mantis/JDK/service_hs_baseline/jdk1.6/solaris-i586/lib/tools.jar
PATH=/net/vmsqe.sfbay/export/nightly/mantis/JDK/service_hs_baseline/jdk1.6/solaris-i586/bin:/net/vmsqe.sfbay/export/nightly/mantis/JDK/service_hs_baseline/jdk1.6/solaris-i586/jre/bin:/bin:/usr/bin:/net/vmsqe.sfbay/export/nightly/mantis/JDK/service_hs_baseline/jdk1.6/solaris-i586/jre/bin
HOME=/home/fhsu

while [ $# -gt 0 ];
do
  if [ $1 = "-jdk" ]; then
	shift 1
	PATH=${1}/bin:${PATH}
	shift 1
  else
	if [ $1 = "-d" ]; then
	  shift 1
	  if [ $# -gt 0  ]; then
		DISPLAY=$1
		shift 1
	  else
		DISPLAY=:0.0
	  fi
	fi
  fi
done

export LD_LIBRARY_PATH
export RAS_OPTIONS
export SHELL
export DISPLAY
export CLASSPATH
export PATH
export HOME

#annotate TEST javaopt=-client -Xcomp -Xss2m "-agentlib:HotSwap=-waittime=2 package=nsk samples=100 mode=compiled bci=call"
/net/vmsqe.sfbay/export/nightly/mantis/JDK/service_hs_baseline/jdk1.6/solaris-i586/bin/java -client -Xcomp -DHANGINGJAVA28222 -Xss2m "-agentlib:HotSwap=-waittime=2 package=nsk samples=100 mode=compiled bci=call" nsk.jvmti.scenarios.hotswap.HS101.hs101t004
##Exit status of execution step=6
##Core file exists
##!checkExitCode

#Failed dependency of type evol_method
#  method  = {method} 'ackermann' '(IJ)J' in 'nsk/jvmti/scenarios/hotswap/HS101/hs101t004Thread'
#  witness = nsk.jvmti.scenarios.hotswap.HS101.hs101t004Thread
## To suppress the following error report, specify this argument
## after -XX: or in .hotspotrc:  SuppressErrorAt=/ciEnv.cpp:717]
##
## An unexpected error has been detected by HotSpot Virtual Machine:
##
##  Internal Error (/net/prt-solx86-q1-1/PrtBuildDir/workspace/src/share/vm/ci/ciEnv.cpp, 717), pid=3553, tid=6
##
## Java VM: Java HotSpot(TM) Client VM (20050922115509.dcubed.service_hs_merge-debug compiled mode)
##
## Error: assert(counter_changed,"failed dependencies, but counter didn't change")
## An error report file with more information is saved as hs_err_pid3553.log
##
## If you would like to submit a bug report, please visit:
##   http://java.sun.com/webapps/bugreport/crash.jsp
##
#Current thread is 6
#Dumping core ...
A pstack dump related to the .tlog and .hs_err above (the tictoc.sfbay is a Solaris 10 machine):

ss45998@tictoc pstack core | c++filt
core 'core' of 24441:   /net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/b
-----------------  lwp# 1 / thread# 1  --------------------
 d276d5e5 ___nanosleep (1) + 15
 d13461c8 THREAD_sleep (1) + 30
 d134bf62 nsk_jvmti_sleep (3e8, 0) + 5a
 d134c14c syncDebugeeStatus (808db04, 8077ac4, 0) + 1d4
 d134c429 Java_nsk_share_jvmti_DebugeeClass_checkStatus (808db04, 8046cc4, 0, 8046cd0, cad82018, cad822a8) + 61
 cf17e760 * *nsk/share/jvmti/DebugeeClass.checkStatus(I)I
 cf16c3e4 ???????? (c6c040e8, 8046d78, d160f7e0, cad81aa8, 2, 0) + 5f0
 cf16bdf4 ???????? (808da00, d23e256a, 808da00, cf000244, c6c386a8, cad81aa8) + 16bb64
 cf000290 * StubRoutines (1)
 d172f6c4 void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*) (8047094, 8046ef4, 8046f30, 808da00, cad81aa8, cad81a68) + 52c
 d1a82edf void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*) (d172f198, 8047094, 8046ef4, 8046f30, 808da00) + 17
 d172f16c void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*) (8047094, 808e29c, 8046f30, 808da00) + 3c
 d17598c4 void jni_invoke_static(JNIEnv_*,JavaValue*,_jobject*,JNICallType,_jmethodID*,JNI_ArgumentPusher*,Thread*) (808db04, 8047094, 0, 0, 839b559, 80470a0) + 3dc
 d178b288 jni_CallStaticVoidMethod (808db04, 808e9d0, 839b559, 808e9bc) + 428
 0805278a main     (0, 80711b4, 8047a34) + 13c6
 0805132e ???????? (7, 8047abc, 8047b0a, 8047b12, 8047b1a, 8047b21) + 805132e
-----------------  lwp# 2 / thread# 2  --------------------
 d276e9b5 ___lwp_cond_wait (808c3b0, 808c398, d1153c78) + 15
 d275b4af _lwp_cond_timedwait (808c3b0, 808c398, d1153ca0) + 35
 d1a53a20 bool Monitor::wait(bool,long) (808c2f8, 1, 3e8) + 7b4
 d1c3f070 void VMThread::loop() (8198e00) + 150
 d1c3ea0f void VMThread::run() (8198e00) + a3
 d1a7dfb4 java_start (8198e00) + dc
 d276cf3f _thr_setup (d26c2400) + 4e
 d276d230 _lwp_start (d26c2400, 0, 0, d1153ff8, d276d230, d26c2400)
-----------------  lwp# 3 / thread# 3  --------------------
 d276e9b5 ___lwp_cond_wait (81a00a4, 81a008c) + 15
 d1a84e25 void PlatformEvent::park() (81a0058) + cd
 d1b41f4e void ObjectMonitor::wait(long long,bool,Thread*) (81a05c0, 0, 0, 1, 819f300) + 432
 d1b3c2ef void ObjectSynchronizer::wait(Handle,long long,Thread*) (819fb50, 0, 0, 819f300, 191) + 22b
 d17fed33 JVM_MonitorWait (819f404, cee78af0, 0, 0, cac29340, 819fb50) + 583
 cf00c580 * java/lang/Object.wait(J)V+0
 cf002e2d * java/lang/Object.wait()V+2
 cf002e2d * java/lang/ref/Reference$ReferenceHandler.run()V+46
 cf000244 * StubRoutines (1)
 d172f6c4 void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*) (cee78e74, cee78cd8, cee78d80, 819f300, 1, 819f300) + 52c
 d1a82edf void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*) (d172f198, cee78e74, cee78cd8, cee78d80, 819f300) + 17
 d172f16c void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*) (cee78e74, 819fb48, cee78d80, 819f300) + 3c
 d172e4b1 void JavaCalls::call_virtual(JavaValue*,KlassHandle,symbolHandle,symbolHandle,JavaCallArguments*,Thread*) (cee78e74, 819fb3c, d24121dc, d24122b8, cee78d80, 819f300) + 249
 d172e6c2 void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,symbolHandle,symbolHandle,Thread*) (cee78e74, 819fb38, 819fb3c, d24121dc, d24122b8, 819f300) + d2
 d1837398 void thread_entry(JavaThread*,Thread*) (819f300, 819f300) + 1a4
 d1b7ee8e void JavaThread::thread_main_inner() (819f300) + 14a
 d1b7ec62 void JavaThread::run() (819f300) + 342
 d1a7dfb4 java_start (819f300) + dc
 d276cf3f _thr_setup (d1100000) + 4e
 d276d230 _lwp_start (d1100000, 0, 0, cee78ff8, d276d230, d1100000)
-----------------  lwp# 4 / thread# 4  --------------------
 d276e9b5 ___lwp_cond_wait (81a4574, 81a455c) + 15
 d1a84e25 void PlatformEvent::park() (81a4528) + cd
 d1b41f4e void ObjectMonitor::wait(long long,bool,Thread*) (81a0624, 0, 0, 1, 81a3800) + 432
 d1b3c2ef void ObjectSynchronizer::wait(Handle,long long,Thread*) (81a4020, 0, 0, 81a3800, 191) + 22b
 d17fed33 JVM_MonitorWait (81a3904, c6bfd93c, 0, 0, c6c00ac8, c6bfd904) + 583
 cf00c580 * java/lang/Object.wait(J)V+0
 cf002e2d * java/lang/ref/ReferenceQueue.remove(J)Ljava/lang/ref/Reference;+44
 cf002ce3 * java/lang/ref/ReferenceQueue.remove()Ljava/lang/ref/Reference;+2
 cf002ce3 * java/lang/ref/Finalizer$FinalizerThread.run()V+3
 cf000244 * StubRoutines (1)
 d172f6c4 void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*) (c6bfdcf4, c6bfdb58, c6bfdc00, 81a3800, 1, 81a3800) + 52c
 d1a82edf void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*) (d172f198, c6bfdcf4, c6bfdb58, c6bfdc00, 81a3800) + 17
 d172f16c void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*) (c6bfdcf4, 81a4018, c6bfdc00, 81a3800) + 3c
 d172e4b1 void JavaCalls::call_virtual(JavaValue*,KlassHandle,symbolHandle,symbolHandle,JavaCallArguments*,Thread*) (c6bfdcf4, 81a400c, d24121dc, d24122b8, c6bfdc00, 81a3800) + 249
 d172e6c2 void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,symbolHandle,symbolHandle,Thread*) (c6bfdcf4, 81a4008, 81a400c, d24121dc, d24122b8, 81a3800) + d2
 d1837398 void thread_entry(JavaThread*,Thread*) (81a3800, 81a3800) + 1a4
 d1b7ee8e void JavaThread::thread_main_inner() (81a3800) + 14a
 d1b7ec62 void JavaThread::run() (81a3800) + 342
 d1a7dfb4 java_start (81a3800) + dc
 d276cf3f _thr_setup (d1100400) + 4e
 d276d230 _lwp_start (d1100400, 0, 0, c6bfdff8, d276d230, d1100400)
-----------------  lwp# 5 / thread# 5  --------------------
 d276d2a9 __lwp_park (d2416118, 0, c69fbc04, d1a80648, d2416118, d23e256a) + 19
 d27633a0 sema_wait (d2416118) + d
 d1a80648 int check_pending_signals(bool) (1, 0, c69fbdb4, d1a78e81, c69fbdb4, d1a78e89) + 1f4
 d1a8087d int os::signal_wait() (d23e256a, 81c0200, d23b0dac, 0, 0, 0) + d
 d1a78e89 void signal_thread_entry(JavaThread*,Thread*) (81c0200, 81c0200) + 2d
 d1b7ee8e void JavaThread::thread_main_inner() (81c0200) + 14a
 d1b7ec62 void JavaThread::run() (81c0200) + 342
 d1a7dfb4 java_start (81c0200) + dc
 d276cf3f _thr_setup (d1100800) + 4e
 d276d230 _lwp_start (d1100800, 0, 0, c69fbff8, d276d230, d1100800)
-----------------  lwp# 6 / thread# 6  --------------------
 d276e875 _lwp_kill (6, 6) + 15
 d271adbb raise    (6) + 1f
 d26fe909 abort    (d240af78, d231c5b7, d23b0dac, d23f80dc, d10fd4b8, 0) + cd
 d1a7f495 void os::abort(bool) (1) + 105
 d1c16f30 void VMError::report_and_die() (d10fd5a0) + 61c
 d1663c64 void report_assertion_failure(const char*,int,const char*) (d1d8a5ec, 2cd, d1d8a5a3) + 5c
 d15736e0 void ciEnv::check_for_system_dictionary_modification(ciMethod*) (d10fd920, 83e3db0) + 1e8
 d15738ca void ciEnv::register_method(ciMethod*,int,int,int,int,CodeBuffer*,int,OopMapSet*,ExceptionHandlerTable*,ImplicitExceptionTable*,AbstractCompiler*,bool,bool) (d10fd920, 83e3db0, ffffffff, 10, 1d, 0) + 1da
 d14c45cb void Compilation::install_code(CodeOffsets*,int) (d10fd810, d10fd790, ffffffff) + 8f
 d14c46b2 void Compilation::compile_method() (d10fd810) + da
 d14c4b42 Compilation::Compilation #Nvariant 1(AbstractCompiler*,ciEnv*,ciMethod*,int,C1_MacroAssembler*) (d10fd810, 81bd9d8, d10fd920, 83e3db0, ffffffff, 81c1e30) + 1c6
 d14c6b91 void Compiler::compile_method(ciEnv*,ciMethod*,int) (81bd9d8, d10fd920, 83e3db0, ffffffff) + 81
 d1618eac void CompileBroker::invoke_compiler_on_method(CompileTask*) (81c3740) + a90
 d1617bea void CompileBroker::compiler_thread_loop() (d23b0dac, d10fdc48, d10fdcc8, d1b7ee8e, 81c1900, 81c1900) + 8d6
 d1b85932 void compiler_thread_entry(JavaThread*,Thread*) (81c1900, 81c1900) + 2a
 d1b7ee8e void JavaThread::thread_main_inner() (81c1900) + 14a
 d1b7ec62 void JavaThread::run() (81c1900) + 342
 d1a7dfb4 java_start (81c1900) + dc
 d276cf3f _thr_setup (d1100c00) + 4e
 d276d230 _lwp_start (d1100c00, 0, 0, d10fdff8, d276d230, d1100c00)
-----------------  lwp# 7 / thread# 7  --------------------
 d276e9b5 ___lwp_cond_wait (808ace0, 808acc8) + 15
 d1a53a7a bool Monitor::wait(bool,long) (808ac28, 1, 0) + 80e
 d1a03395 void LowMemoryDetector::low_memory_detector_thread_entry(JavaThread*,Thread*) (81fff00, 81fff00) + 1f1
 d1b7ee8e void JavaThread::thread_main_inner() (81fff00) + 14a
 d1b7ec62 void JavaThread::run() (81fff00) + 342
 d1a7dfb4 java_start (81fff00) + dc
 d276cf3f _thr_setup (d1101000) + 4e
 d276d230 _lwp_start (d1101000, 0, 0, c67f9ff8, d276d230, d1101000)
-----------------  lwp# 8 / thread# 8  --------------------
 d276e305 __pollsys (0, 0, d10bba90, 0) + 15
 d2718546 poll     (0, 0, 32) + 52
 d1a81448 int os_sleep(long long,bool) (32, 0, 0, 8202d00) + 1cc
 d1a81830 int os::sleep(Thread*,long long,bool) (8202d00, 32, 0, 0, d1b7d8b6) + 224
 d1b7d8c7 void WatcherThread::run() (8202d00) + 1a3
 d1a7dfb4 java_start (8202d00) + dc
 d276cf3f _thr_setup (d1101400) + 4e
 d276d230 _lwp_start (d1101400, 0, 0, d10bbff8, d276d230, d1101400)
-----------------  lwp# 9 / thread# 9  --------------------
 d276e9b5 ___lwp_cond_wait (83bebac, 83beb94, c65f7958) + 15
 d275b4af _lwp_cond_timedwait (83bebac, 83beb94, c65f7988) + 35
 d1a85029 int PlatformEvent::park(long long) (83beb60, 64, 0) + 101
 d1b43854 int ObjectMonitor::SimpleWait(Thread*,long long) (83bef18, 83be600, 64, 0) + dc
 d1b4416f int ObjectMonitor::raw_wait(long long,bool,Thread*) (83bef18, 64, 0, 1, 83be600) + b3
 d1972c63 jvmtiError JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long long) (8077ac0, 83bef18, 64, 0) + ab
 d18c59ff jvmti_RawMonitorWait (8077ac4, 83bef18, 64, 0) + 12f
 d1344a86 wait_for (8077ac4, 64, 0) + f6
 d1344cf6 agentProc (8077ac4, 83be704, 0) + 186
 d134b8ce agentThreadWrapper (8077ac4, 83be704, 0) + 86
 d19ac2ab void JvmtiAgentThread::call_start_function() (83be600) + 47
 d19ac1f5 void JvmtiAgentThread::start_function_wrapper(JavaThread*,Thread*) (83be600, 83be600) + 8d
 d1b7ee8e void JavaThread::thread_main_inner() (83be600) + 14a
 d1b7ec62 void JavaThread::run() (83be600) + 342
 d1a7dfb4 java_start (83be600) + dc
 d276cf3f _thr_setup (d1101800) + 4e
 d276d230 _lwp_start (d1101800, 0, 0, c65f7ff8, d276d230, d1101800)
-----------------  lwp# 10 / thread# 10  --------------------
 d276e9b5 ___lwp_cond_wait (81c3860, 81c3848) + 15
 d1a53784 bool Monitor::wait(bool,long) (81c37a8, 0, 0) + 518
 d1617192 nmethod*CompileBroker::wait_for_completion(CompileTask*) (81c3740) + 2da
 d161482e nmethod*CompileBroker::compile_method_base(methodHandle,int,int,methodHandle,int,const char*,Thread*) (83bcbd4, ffffffff, 2, 83bcbd4, 5dc, d1e0cd4b) + 5be
 d1615578 nmethod*CompileBroker::compile_method(methodHandle,int,methodHandle,int,const char*,Thread*) (83bcbd4, ffffffff, 83bcbd4, 5dc, d1e0cd4b, 83c4700) + ba0
 d160fe99 void SimpleCompPolicy::method_invocation_event(methodHandle,Thread*) (8122670, 83bcbd4, 83c4700) + 159
 d171660b nmethod*InterpreterRuntime::frequency_counter_overflow(JavaThread*,unsigned char*) (83c4700, 0, cf00b384, c63b93c0, cb101778, c63b93f4) + 109f
 cf00b3c8 * nsk/jvmti/scenarios/hotswap/HS101/hs101t004Thread.ackermann(IJ)J+0
 cf002d67 * nsk/jvmti/scenarios/hotswap/HS101/hs101t004Thread.ackermann(IJ)J+35
 ....................................................................
 cf17fcc4 ???????? (83c4700, d23e256a, 83c4700, cf000244, c6c50910, d23e256a) + 17fa34
 cf000290 * StubRoutines (1)
 d172f6c4 void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*) (c63f5df4, c63f5c58, c63f5d00, 83c4700, 1, 83c4700) + 52c
 d1a82edf void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*) (d172f198, c63f5df4, c63f5c58, c63f5d00, 83c4700) + 17
 d172f16c void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*) (c63f5df4, 83bcbc0, c63f5d00, 83c4700) + 3c
 d172e4b1 void JavaCalls::call_virtual(JavaValue*,KlassHandle,symbolHandle,symbolHandle,JavaCallArguments*,Thread*) (c63f5df4, 83bcbb4, d24121dc, d24122b8, c63f5d00, 83c4700) + 249
 d172e6c2 void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,symbolHandle,symbolHandle,Thread*) (c63f5df4, 83bcbb0, 83bcbb4, d24121dc, d24122b8, 83c4700) + d2
 d1837398 void thread_entry(JavaThread*,Thread*) (83c4700, 83c4700) + 1a4
 d1b7ee8e void JavaThread::thread_main_inner() (83c4700) + 14a
 d1b7ec62 void JavaThread::run() (83c4700) + 342
 d1a7dfb4 java_start (83c4700) + dc
 d276cf3f _thr_setup (d1101c00) + 4e
 d276d230 _lwp_start (d1101c00, 0, 0, c63f5ff8, d276d230, d1101c00)
The following is another .tlog file and a corresponding hs_err dump:

ss45998@tictoc cat /net/tomsk.sfbay/export/home/ss45998/1.5/tst/nsk_regr/hs_dtr.Oct11.x86/ss45998.Solaris.x86/hs101t004/hs101t004.tlog
#!/bin/sh

LD_LIBRARY_PATH=/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6/vm/bin/lib/intel/nsk/share/jvmti/hotswap:/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6/vm/src/nsk/share/lib/intel:/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/jre/lib/i386/client
RAS_OPTIONS=
SHELL=/bin/sh
DISPLAY=bratsk:1.0
CLASSPATH=/net/tomsk.sfbay/export/home/ss45998/1.5/tst/nsk_regr/hs_dtr.Oct11.x86/ss45998.Solaris.x86/hs101t004:/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6/vm/bin/classes:/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/lib/tools.jar
PATH=/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/bin:/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/jre/bin:/bin:/usr/bin
HOME=/home/ss45998

while [ $# -gt 0 ];
do
  if [ $1 = "-jdk" ]; then
        shift 1
        PATH=${1}/bin:${PATH}
        shift 1
  else
        if [ $1 = "-d" ]; then
          shift 1
          if [ $# -gt 0  ]; then
                DISPLAY=$1
                shift 1
          else
                DISPLAY=:0.0
          fi
        fi
  fi
done

export LD_LIBRARY_PATH
export RAS_OPTIONS
export SHELL
export DISPLAY
export CLASSPATH
export PATH
export HOME

#annotate TEST javaopt=-client -client -Xcomp -Xss2m "-agentlib:HotSwap=-waittime=2 package=nsk samples=100 mode=compiled bci=call"
/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/bin/java -client -client -Xcomp -Xss2m "-agentlib:HotSwap=-waittime=2 package=nsk samples=100 mode=compiled bci=call" nsk.jvmti.scenarios.hotswap.HS101.hs101t004
##Exit status of execution step=6
##Core file exists
##!checkExitCode

#Failed dependency of type evol_method
#check_evol_method: obsolete: 1, brkpt_cnt: 0
#check_evol_method: obsolete: 1, brkpt_cnt: 0
#check_evol_method: obsolete: 1, brkpt_cnt: 0
#check_evol_method: obsolete: 1, brkpt_cnt: 0
#check_evol_method: obsolete: 1, brkpt_cnt: 0
#  method  = {method} 'ackermann' '(IJ)J' in 'nsk/jvmti/scenarios/hotswap/HS101/hs101t004Thread'
#  witness = nsk.jvmti.scenarios.hotswap.HS101.hs101t004Thread
## To suppress the following error report, specify this argument
## after -XX: or in .hotspotrc:  SuppressErrorAt=/ciEnv.cpp:717]
##
## An unexpected error has been detected by HotSpot Virtual Machine:
##
##  Internal Error (/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr/src/share/vm/ci/ciEnv.cpp, 717), pid=24441, tid=6
##
## Java VM: Java HotSpot(TM) Client VM (1.6.0-internal-debug compiled mode)
##
## Error: assert(counter_changed,"failed dependencies, but counter didn't change")
## An error report file with more information is saved as hs_err_pid24441.log
##
## If you would like to submit a bug report, please visit:
##   http://java.sun.com/webapps/bugreport/crash.jsp
##
#Current thread is 6
#Dumping core ...

ss45998@tictoc cd /net/tomsk.sfbay/export/home/ss45998/1.5/tst/nsk_regr/hs_dtr.Oct11.x86/

ss45998@tictoc hs_err hs_err_pid24441.log | c++filt
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  Internal Error (/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr/src/share/vm/ci/ciEnv.cpp, 717), pid=24441, tid=6
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-internal-debug compiled mode)
#
# Error: assert(counter_changed,"failed dependencies, but counter didn't change")

---------------  T H R E A D  ---------------

Current thread (0x081c1900):  JavaThread "CompilerThread0" daemon [_thread_in_vm, id=6]

Stack: [0xd10be000,0xd10fe000),  sp=0xd10fd4d8,  free space=253k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x816df6];;  void VMError::report_and_die()+0x4e2
V  [libjvm.so+0x263c64];;  void report_assertion_failure(const char*,int,const char*)+0x5c
V  [libjvm.so+0x1736e0];;  void ciEnv::check_for_system_dictionary_modification(ciMethod*)+0x1e8
V  [libjvm.so+0x1738ca];;  void ciEnv::register_method(ciMethod*,int,int,int,int,CodeBuffer*,int,OopMapSet*,ExceptionHandlerTable*,ImplicitExceptionTable*,AbstractCompiler*,bool,bool)+0x1da
V  [libjvm.so+0xc45cb];;  void Compilation::install_code(CodeOffsets*,int)+0x8f
V  [libjvm.so+0xc46b2];;  void Compilation::compile_method()+0xda
V  [libjvm.so+0xc4b42];;  Compilation::Compilation(AbstractCompiler*,ciEnv*,ciMethod*,int,C1_MacroAssembler*)+0x1c6
V  [libjvm.so+0xc6b91];;  void Compiler::compile_method(ciEnv*,ciMethod*,int)+0x81
V  [libjvm.so+0x218eac];;  void CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa90
V  [libjvm.so+0x217bea];;  void CompileBroker::compiler_thread_loop()+0x8d6
V  [libjvm.so+0x785932];;  void compiler_thread_entry(JavaThread*,Thread*)+0x2a
V  [libjvm.so+0x77ee8e];;  void JavaThread::thread_main_inner()+0x14a
V  [libjvm.so+0x77ec62];;  void JavaThread::run()+0x342
V  [libjvm.so+0x67dfb4];;  java_start+0xdc
C  [libc.so.1+0x9cf3f];;  _thr_setup+0x4e
C  [libc.so.1+0x9d230];;  _lwp_start+0x0


Current CompileTask:
HotSpot Client Compiler:348   b  nsk.jvmti.scenarios.hotswap.HS101.hs101t004Thread.ackermann(IJ)J (42 bytes)


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x083c4700 JavaThread "Debuggee Thread" [_thread_blocked, id=10]
  0x083be600 JavaThread "JVMTI agent thread" daemon [_thread_blocked, id=9]
  0x081fff00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7]
=>0x081c1900 JavaThread "CompilerThread0" daemon [_thread_in_vm, id=6]
  0x081c0200 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=5]
  0x081a3800 JavaThread "Finalizer" daemon [_thread_blocked, id=4]
  0x0819f300 JavaThread "Reference Handler" daemon [_thread_blocked, id=3]
  0x0808da00 JavaThread "main" [_thread_in_native, id=1]

Other Threads:
  0x08198e00 VMThread [id=2]
  0x08202d00 WatcherThread [id=8]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x0808d258/0x0808d2b8] Compile_lock - owner thread: 0x081c1900
[0x0808d538/0x0808d5a8] MethodCompileQueue_lock - owner thread: 0x081c1900

Heap
 def new generation   total 576K, used 346K [0xc6c00000, 0xc6ca0000, 0xc70e0000)
  eden space 512K,  67% used [0xc6c00000, 0xc6c56ac0, 0xc6c80000)
  from space 64K,   0% used [0xc6c80000, 0xc6c80000, 0xc6c90000)
  to   space 64K,   0% used [0xc6c90000, 0xc6c90000, 0xc6ca0000)
 tenured generation   total 1408K, used 0K [0xc70e0000, 0xc7240000, 0xcac00000)
   the space 1408K,   0% used [0xc70e0000, 0xc70e0000, 0xc70e0200, 0xc7240000)
 compacting perm gen  total 12288K, used 5181K [0xcac00000, 0xcb800000, 0xcec00000)
   the space 12288K,  42% used [0xcac00000, 0xcb10f5b0, 0xcb10f600, 0xcb800000)
No shared spaces configured.

Dynamic libraries:
0x08050000      /net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.b52/i386/jdk1.6.0/bin/java
0xd27c0000      /lib/libthread.so.1
0xd27d0000      /lib/libdl.so.1
0xd26d0000      /lib/libc.so.1
0xd1400000      /net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.b52/i386/jdk1.6.0/jre/lib/i386/client/libjvm.so
0xd2680000      /lib/libsocket.so.1
0xd26b0000      /usr/lib/libsched.so.1
0xd2640000      /usr/lib/libCrun.so.1
0xd25e0000      /lib/libm.so.2
0xd25b0000      /lib/libdoor.so.1
0xd2520000      /lib/libnsl.so.1
0xd24f0000      /lib/libscf.so.1
0xd24c0000      /lib/libuutil.so.1
0xd24a0000      /lib/libmd5.so.1
0xd2480000      /lib/libmp.so.2
0xd13a0000      /net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.b52/i386/jdk1.6.0/jre/lib/i386/native_threads/libhpi.so
0xd1370000      /lib/libm.so.1
0xd1340000      /net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6/vm/bin/lib/intel/nsk/share/jvmti/hotswap/libHotSwap.so
0xd1300000      /net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.b52/i386/jdk1.6.0/jre/lib/i386/libverify.so
0xd12b0000      /net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.b52/i386/jdk1.6.0/jre/lib/i386/libjava.so
0xd1280000      /net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.b52/i386/jdk1.6.0/jre/lib/i386/libzip.so

VM Arguments:
jvm_args: -Xcomp -Xss2m -agentlib:HotSwap=-waittime=2 package=nsk samples=100 mode=compiled bci=call
java_command: nsk.jvmti.scenarios.hotswap.HS101.hs101t004
Launcher Type: SUN_STANDARD

Environment Variables:
CLASSPATH=/net/tomsk.sfbay/export/home/ss45998/1.5/tst/nsk_regr/hs_dtr.Oct11.x86/ss45998.Solaris.x86/hs101t004:/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6/vm/bin/classes:/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/lib/tools.jar
PATH=/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/bin:/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/jre/bin:/bin:/usr/bin
LD_LIBRARY_PATH=/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.b52/i386/jdk1.6.0/jre/lib/i386/client:/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.b52/i386/jdk1.6.0/jre/lib/i386:/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.b52/i386/jdk1.6.0/jre/../lib/i386:/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6/vm/bin/lib/intel/nsk/share/jvmti/hotswap:/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6/vm/src/nsk/share/lib/intel:/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/jre/lib/i386/client
SHELL=/bin/sh
DISPLAY=bratsk:1.0

Signal Handlers:
SIGSEGV: [libjvm.so+0x81798c], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGBUS: [libjvm.so+0x81798c], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGFPE: [libjvm.so+0x682ee4], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGPIPE: [libjvm.so+0x682ee4], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGILL: [libjvm.so+0x682ee4], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGHUP: [libjvm.so+0x680158], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGINT: [libjvm.so+0x680158], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGQUIT: [libjvm.so+0x680158], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGTERM: [libjvm.so+0x680158], sa_mask[0]=0xffbffeff, sa_flags=0x00000004


---------------  S Y S T E M  ---------------

OS:                           Solaris 10 3/05 s10_74L1 X86
           Copyright 2004 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                           Assembled 29 December 2004

uname:SunOS 5.10 s10_74l1 i86pc  (T2 libthread)
rlimit: STACK 8480k, CORE infinity, NOFILE 65536, AS infinity
load average:0.68 0.58 0.48

CPU:total 2 family 6, cmov, cx8, fxsr, mmx

Memory: 4k page, physical 523836k(323124k free)

vm_info: Java HotSpot(TM) Client VM (1.6.0-internal) for solaris-x86, built on Oct 11 2005 01:17:30 by "ss45998" with unknown Workshop:0x570

Comments
EVALUATION I have never seen this crash for C2. And I can not reproduce it with C2 either. But it is well reproducible with C1. It looks like a guard of the method obsoleteness is missed for C1. I hope that a crash log with tracing below is a prove that it is missed. The question is where it is supposed to be. Please, see the crash log below and the webrev file hs_dtr.Oct17.tar.gz with my tracing in attachment. The webrev includes a bunch of hacks to print out the tracing information. The tracing includes the SD tick values and results of the test method()->is_obsolete in different points. This is the crash log: ss45998@tictoc cat /net/tomsk.sfbay/export/home/ss45998/1.5/tst/nsk_regr/hs_dtr.Oct17.x86/ss45998.Solaris.x86/hs101t004/hs101t004.tlog #!/bin/sh LD_LIBRARY_PATH=/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6/vm/bin/lib/intel/nsk/share/jvmti/hotswap:/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6/vm/src/nsk/share/lib/intel:/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/jre/lib/i386/client RAS_OPTIONS= SHELL=/bin/sh DISPLAY=bratsk:1.0 CLASSPATH=/net/tomsk.sfbay/export/home/ss45998/1.5/tst/nsk_regr/hs_dtr.Oct17.x86/ss45998.Solaris.x86/hs101t004:/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6/vm/bin/classes:/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/lib/tools.jar PATH=/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/bin:/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/jre/bin:/bin:/usr/bin HOME=/home/ss45998 ... #annotate TEST javaopt=-client -client -Xcomp -Xss2m "-agentlib:HotSwap=-waittime=2 package=nsk samples=100 mode=compiled bci=call" /net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr.latest/i386/jdk1.6.0/bin/java -client -client -Xcomp -Xss2m "-agentlib:HotSwap=-waittime=2 package=nsk samples=100 mode=compiled bci=call" nsk.jvmti.scenarios.hotswap.HS101.hs101t004 ##Exit status of execution step=6 ##Core file exists ##!checkExitCode # # ciEnv::system_dictionary_modification_counter_changed: # recorded SD tick: 333, current SD tick: 334 #check_evol_method: is_obsolete: 1, brkpt_cnt: 0, SD tick: 334 #check_dependency was called from ciEnv::check_for_system_dictionary_modification # #check_evol_method: is_obsolete: 1, brkpt_cnt: 0, SD tick: 338 # # ciEnv::system_dictionary_modification_counter_changed: # recorded SD tick: 337, current SD tick: 338 #check_evol_method: is_obsolete: 1, brkpt_cnt: 0, SD tick: 338 #check_dependency was called from ciEnv::check_for_system_dictionary_modification # # # ciEnv::system_dictionary_modification_counter_changed: # recorded SD tick: 354, current SD tick: 355 #check_evol_method: is_obsolete: 1, brkpt_cnt: 0, SD tick: 355 #check_dependency was called from ciEnv::check_for_system_dictionary_modification # #check_evol_method: is_obsolete: 1, brkpt_cnt: 0, SD tick: 380 #CompileBroker::invoke_compiler_on_method: is_obsolete: 1, SD tick: 380 #!!Must not compile method if it is obsolete when the SD tick has been sampled!! #!!See a assertion crash with the same SD tick=380 after that point!! # #check_evol_method: is_obsolete: 1, brkpt_cnt: 0, SD tick: 380 #check_dependency was called from ciEnv::check_for_system_dictionary_modification # #Failed dependency of type evol_method <== ss45998: Note, this happens with the same SD tick = 380!!! # method = {method} 'ackermann' '(IJ)J' in 'nsk/jvmti/scenarios/hotswap/HS101/hs101t004Thread' # witness = nsk.jvmti.scenarios.hotswap.HS101.hs101t004Thread ## To suppress the following error report, specify this argument ## after -XX: or in .hotspotrc: SuppressErrorAt=/ciEnv.cpp:735] ## ## An unexpected error has been detected by HotSpot Virtual Machine: ## ## Internal Error (/net/tomsk.sfbay/export/home/ss45998/1.5/hs_dtr/src/share/vm/ci/ciEnv.cpp, 735), pid=5636, tid=6 ## ## Java VM: Java HotSpot(TM) Client VM (1.6.0-internal-debug compiled mode) ## ## Error: assert(counter_changed,"failed dependencies, but counter didn't change") ## An error report file with more information is saved as hs_err_pid5636.log ## ## If you would like to submit a bug report, please visit: ## http://java.sun.com/webapps/bugreport/crash.jsp ## #Current thread is 6 #Dumping core ... The following simple fix has been suggested by John in email discussion (I add this here because it is different than that in the current Suggested Fix section): This change ought to make C1 check for bad methods like C2 does: ------- c1_Compilation.cpp ------- --- /tmp/sccs.KeaalO Mon Oct 17 11:43:21 2005 +++ c1_Compilation.cpp Mon Oct 17 11:43:09 2005 @@ -382,6 +382,11 @@ // Note: make sure we mark the method as not compilable! if (bailed_out()) return; + if (!method()->can_be_compiled()) { + bailout("Bailing out because method is not compilable"); + return; + } + if (JvmtiExport::can_hotswap_or_post_breakpoint()) { dependency_recorder()->assert_evol_method(method()); }
18-10-2005

SUGGESTED FIX This might plug the hole, if the root cause is a weakness in methodOopDesc::is_not_compilable. The weakness would still be there, and is_not_compilable is not really trustworthy. It may continue to cause the compile broker (who also uses it) to malfunction. ------- ciMethod.cpp ------- --- /tmp/sccs._9aqMh Sun Sep 25 21:15:31 2005 +++ ciMethod.cpp Sun Sep 25 21:15:23 2005 @@ -45,6 +45,14 @@ _flow = NULL; #endif // COMPILER2 + if (_is_compilable) { + // 6328518 Double check compilability under the right lock. + MutexLocker locker(Compile_lock); + if (Dependencies::check_evol_method(h_m()) != NULL) { + _is_compilable = false; + } + } + _can_be_statically_bound = (h_m()->is_final_method() || h_m()->vtable_index() == -1); // %%% Klass::can_be_statically_bound needs to be simplified
26-09-2005

EVALUATION The diagnostic raised by the new code in ciEnv is a new check against possible pre-existing bugs. It appears we have found one. The check asserts that dependencies have not been invalidated during a compilation, unless the system dictionary number_of_modifications counter changes. A likely root cause of this regression is a method replacement, concurrent with compilation, which does not increment the system dictionary counter. Any change which may invalidate dependencies (including evol_method) must also increment the system dictionary counter. These two actions must be taken together atomically with respect to compiler's check, which is (a) in the VM and (b) under the Compile_lock. The evol_method dependency is checked by Dependencies::check_evol_method, which looks for (1) breakpoints and (2) obsoleted methods. I cannot tell from the failing test which condition is being exercised. (In fact, the test code is very "magic" and hard to understand. There is no indication of what the debugger is doing while the subject code runs.) In the VM code, state change (1) could be incr_number_of_breakpoints called from BreakpointInfo::set, which also calls SystemDictionary::notice_modification. State change (2) could be set_is_obsolete in the call chain check_methods_and_mark_as_obsolete <- redefine_single_class <- VM_RedefineClasses::doit. That last function also calls SystemDictionary::notice_modification. The function notice_modification asserts that the proper lock is held. In other words, it is impossible to call notice_modification without already ensuring that associated state changes are atomic with respect to the compiler's final dependency check in ciEnv. So in both cases, I don't see how the JVMTI code can be breaking the dependency without notifying the compiler. The other possibility is a race condition or logic error in the CI code which first touches a method at compile time. Perhaps the compiler is allowed to use a method which is already breakpointed or obsolete. This seems the most likely root cause of the present bug. A change (1/29/2004) in ciMethod for bug 4984394 actually erases breakpoint information from the incoming method, allowing the compiler to compile as if the method were not breakpointed. This looks risky to me. The call from the CI to methodOopDesc::is_not_compilable checks the number of breakpoints, but not at a safepoint or under the Compile_lock. Even worse, is_not_compilable does not appear to check the is_obsolete bit at all. That means that a method can be obsolete on entry to a compile task, and as long as the system dictionary count does not change during the compile, we get all the way to the final check without knowing the method is invalid. A likely root cause of this bug is therefore the interaction between is_not_compilable and JVMTI. If so, this bug is pre-existing, and should probably be analyzed and fixed by an engineer familiar with the JVMTI code and with its state transitions. I've suggested a fix, which is to check the dependency explicitly. However, the function is_not_compilable may still be broken.
26-09-2005

EVALUATION I used the prt_isolate script (and the prt_isolate_wrap2 wrapper too) to search a prt putback caused this regression. Current location of the script is /home/ss45998/bin but the intent is to put it into the svc tools directory: /java/svc/tools/bin. The following putback in the c2 baseline is the root cause of the nsk/jvmti/scenarios/hotswap/HS101/hs101t004 regression: FOUND PRT build responsible for the regression: 20050908124746.jrose.mustang-dependencies I used the SQE Solaris 10 x86 machine tictoc.sfbay which is good in reproducing this bug. Please, see the prt_isolation details below. Search in the c2 baseline ------------------------- prt_isolate -baseline c2 -vmkind client -tmpjdk /net/tomsk.sfbay/export/home/ss45998/1.5/hs_fld.latest/i386/jdk1.6.0 -tmpdir default -pattern counter_changed -site west -release current -year 2005 -search binary -vmconfig fastdebug -first default -last 20 -runcount 10 -testrun runnsk -client -Xcomp nsk/jvmti/scenarios/hotswap/HS101/hs101t004 [BEG: Sat Sep 24 04:30:54 PDT 2005] Test script options are: -client -Xcomp nsk/jvmti/scenarios/hotswap/HS101/hs101t004 *** The PRT Binary Search *** First build #1: 20050923130434.nips.main_to_c2_baseline Last build #20: 20050902112626.rasbold.main_to_c2_baseline ITEM 10: 20050914133524.rasbold.c2_baseline PRT dir=<prtroot>/c2_baseline/*/20050914133524.rasbold.c2_baseline/solaris_i486_compiler1/fastdebug singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed ## Error: assert(counter_changed,"failed dependencies, but counter didn't change") singleTestRunStatus=FailedMatch FAILED: 20050914133524.rasbold.c2_baseline ITEM 15: 20050912083939.nips.main_to_c2_baseline PRT dir=<prtroot>/c2_baseline/*/20050912083939.nips.main_to_c2_baseline/solaris_i486_compiler1/fastdebug singleTestRunStatus=Passed singleTestRunStatus=Passed ## Error: assert(counter_changed,"failed dependencies, but counter didn't change") singleTestRunStatus=FailedMatch FAILED: 20050912083939.nips.main_to_c2_baseline ITEM 18: 20050908124746.jrose.mustang-dependencies PRT dir=<prtroot>/c2_baseline/*/20050908124746.jrose.mustang-dependencies/solaris_i486_compiler1/fastdebug singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed ## Error: assert(counter_changed,"failed dependencies, but counter didn't change") singleTestRunStatus=FailedMatch FAILED: 20050908124746.jrose.mustang-dependencies ITEM 19: 20050908003717.kbr.c2_baseline PRT dir=<prtroot>/c2_baseline/*/20050908003717.kbr.c2_baseline/solaris_i486_compiler1/fastdebug singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed singleTestRunStatus=Passed passed: 20050908003717.kbr.c2_baseline FOUND PRT build responsible for the regression: 20050908124746.jrose.mustang-dependencies prt_isolate -baseline c2 -vmkind client -tmpjdk /net/tomsk.sfbay/export/home/ss45998/1.5/hs_fld.latest/i386/jdk1.6.0 -tmpdir default -pattern counter_changed -site west -release current -year 2005 -search binary -vmconfig fastdebug -first default -last 20 -runcount 10 -testrun runnsk -client -Xcomp nsk/jvmti/scenarios/hotswap/HS101/hs101t004 [END: Sat Sep 24 05:35:25 PDT 2005] *** (#1 of 1): [ UNSAVED ] ###@###.###
26-09-2005