Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6369191

Calling DisposeEnvironment in callback causes crash if there are multiple environments

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: 6
    • Fix Version/s: 6
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:
      b92
    • CPU:
      generic
    • OS:
      generic

      Description

      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).

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                rfield Robert Field
                Reporter:
                alanb Alan Bateman
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: