nsk/jvmti/AttachOnDemand/attach014 failed in the nightly with:

#
# An unexpected error has been detected by Java Runtime Environment:
#
# Internal Error (/net/prt-solsparc-q1-16/tmp/PrtBuildDir/workspace/src/share/vm/utilities/growableArray.hpp, 157 [ Patched ]), pid=17549, tid=2
#
# Java VM: Java HotSpot(TM) Client VM (20060104125724.dcubed.mustang-redefine-classes-queue-debug compiled mode, sharing)
#
# Error: assert(0 <= i && i < _len,"illegal index")
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

An example failure can be found here:

http://vmsqe.sfbay/nightly/mantis/DTWS/results/01-04-06/ClientVM/Solsparc/comp/Serv_Baseline/nsk.jvmti-NIGHTLY-Serv_Baseline-ClientVM-comp-Solsparc-2006-01-04-19-59-58/analysis_new.html

The decoded stack trace from the error log is:

Stack: [0xfd600000,0xfd6fc000), sp=0xfd6fb038, free space=1004k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xcdbbdc] ;; __1cHVMErrorOreport_and_die6M_v_+0x7f8
V [libjvm.so+0x3a9ce8] ;; __1cYreport_assertion_failure6Fpkci1_v_+0x70
V [libjvm.so+0x8cf968] ;; __1cLJvmtiExportSpost_class_prepare6FpnKJavaThread_nIklassOop__v_+0x4e0
V [libjvm.so+0x4544b0] ;; __1cNinstanceKlassPlink_class_impl6FnTinstanceKlassHandle_pnGThread__v_+0x2818
V [libjvm.so+0x451c3c] ;; __1cNinstanceKlassKlink_class6MpnGThread__v_+0x280
V [libjvm.so+0x454ccc] ;; __1cNinstanceKlassPinitialize_impl6FnTinstanceKlassHandle_pnGThread__v_+0x108
V [libjvm.so+0x451894] ;; __1cNinstanceKlassKinitialize6MpnGThread__v_+0x280
V [libjvm.so+0x1e2ecc] ;; __1cIRuntime1Mnew_instance6FpnKJavaThread_pnMklassOopDesc__v_+0x96c
v ~RuntimeStub::new_instance Runtime1 stub
J nsk.share.jvmti.aod.DefaultAgentTarget.runAgentTarget()V
J nsk.jvmti.AttachOnDemand.attach014.attach014AgentTarget.main([Ljava/lang/String;)V
v ~StubRoutines::call_stub
V [libjvm.so+0x4f89cc] ;; __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x990
V [libjvm.so+0x53f348] ;; __1cRjni_invoke_static6FpnHJNIEnv__pnJJavaValue_pnI_jobject_nLJNICallType_pnK_jmethodID_pnSJNI_Ar
gumentPusher_pnGThread__v_+0x7ec
V [libjvm.so+0x584344] ;; jni_CallStaticVoidMethod+0x7b4
nm: /var/tmp/Work/Work/JDK/NIGHTLY/Serv_Baseline/solaris-sparc/bin/java: No such file or directory
C [java+0x3a6c]

From the error log it appears the issue the callback is invoked from a loop over the environments. If the callback disposes the environment then an element from the growable array of environments is removed which causes the loop to go beyond the end. The bug dates back to the original implementation in 5.0. The issue should only exist in cases where there are multiple JVMTI environments (which is rare).