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

assert(SafepointSynchronize::is_at_safepoint()) failed: must be executed at a safepoint

    Details

    • Subcomponent:
    • Resolved In Build:
      b03
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Verified

      Backports

        Description

        JvmtiExport::post_compiled_method_unload_at_safepoint() is failing in
        the following way:

            Internal Error (src/share/vm/prims/jvmtiExport.cpp:1868), pid=22577, tid=14
            assert(SafepointSynchronize::is_at_safepoint()) failed: must be executed at a safepoint

        Here is the code for the failure point:

           1866 // used at a safepoint to post a CompiledMethodUnload event
           1867 void JvmtiExport::post_compiled_method_unload_at_safepoint(jmethodID mid,
         const void *code_begin) {
           1868 assert(SafepointSynchronize::is_at_safepoint(), "must be executed at a safepoint");
           1869
           1870 // create list lazily
           1871 if (_pending_compiled_method_unload_method_ids == NULL) {

        This assertion failure has been seen in the following VM/NSK tests:

            nsk/jvmti/CompiledMethodUnload/compmethunload001
            nsk/jvmti/RedefineClasses/redefclass028
            nsk/jvmti/RedefineClasses/redefclass029
            nsk/jvmti/RedefineClasses/redefclass030
            nsk/jvmti/scenarios/capability/CM02/cm02t001
            nsk/jvmti/scenarios/events/EM02/em02t003
            nsk/jvmti/scenarios/events/EM05/em05t001
            nsk/jvmti/scenarios/events/EM05/em05t002
            nsk/jvmti/scenarios/events/EM07/em07t002
            nsk/jvmti/scenarios/multienv/MA10/ma10t006

        These failures have been see on Solaris SPARC, Solaris SPARC-V9 and
        Solaris AMD64 configs. Not all of the tests fail in every config in
        evey run.

        Here is a link to the Solaris SPARC Client VM -Xcomp failures:

        http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-05-27/RT_Baseline/vm/solaris-sparc/client/comp/solaris-sparc_client_comp_nsk.jvmti.testlist/analysis.html


        Here is a link Solaris SPARC-V9 Server VM -Xcomp failures:

        http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-05-27/RT_Baseline/vm/solaris-sparcv9/server/comp/solaris-sparcv9_server_comp_nsk.jvmti.testlist/analysis.html


        Here is a link to the Solaris AMD64 Server VM -Xcomp failures:

        http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-05-27/RT_Baseline/vm/solaris-amd64/server/comp/solaris-amd64_server_comp_nsk.jvmti.testlist/analysis.html
        Here is a stack trace snippet from the hs_err file from one of the failures:

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

        Current thread (0x00000001007b7000): JavaThread "CompilerThread1" daemon [_thread_in_vm, id=14, stack(0xffffffff60600000,0xffffffff60700000)]

        Stack: [0xffffffff60600000,0xffffffff60700000], sp=0xffffffff606ff0f0, free space=3fcffffffff7e4cfa40k
        Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
        V [libjvm.so+0xeb10dc];; __1cHVMErrorOreport_and_die6M_v_+0x6bc
        V [libjvm.so+0x504280];; __1cPreport_vm_error6Fpkci11_v_+0x78
        V [libjvm.so+0x983194];; __1cLJvmtiExportbOpost_compiled_method_unload_at_safepoint6FpnK_jmethodID_pkv_v_+0x64
        V [libjvm.so+0xb6c450];; __1cHnmethodbAmake_not_entrant_or_zombie6MI_b_+0x690
        V [libjvm.so+0xd8ab54];; __1cONMethodSweeperQsweep_code_cache6F_v_+0x5b4
        V [libjvm.so+0xd8a578];; __1cONMethodSweeperOpossibly_sweep6F_v_+0x90
        V [libjvm.so+0x467b28];; __1cMCompileQdDueueDget6M_pnLCompileTask__+0x20
        V [libjvm.so+0x46bb38];; __1cNCompileBrokerUcompiler_thread_loop6F_v_+0x270
        V [libjvm.so+0xe033fc];; __1cKJavaThreadRthread_main_inner6M_v_+0x174
        V [libjvm.so+0xe03268];; __1cKJavaThreadDrun6M_v_+0x310
        V [libjvm.so+0xbc8f2c];; java_start+0x184

        The other stacks appear to be similar.
        These failures have also been observed on Linux-AMD64, Win32 and
        Win-AMD64. Changed the call record OS to be "generic". Also changed
        the build to HSX-19-B01 show that failures will show up as "known".
        The sub-baselines have the code the introduced the failures, but
        the hotspot_version bump to HSX-19-B02 hasn't trickled down yet.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  never Tom Rodriguez
                  Reporter:
                  dcubed Daniel Daugherty
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: