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

assert(allocated_on_res_area() || allocated_on_C_heap() || allocated_on_arena()

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: hs19
    • Fix Version/s: hs19
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b06
    • CPU:
      x86
    • OS:
      solaris_10
    • Verification:
      Not verified

      Backports

        Description

        #
        # A fatal error has been detected by the Java Runtime Environment:
        #
        # Internal Error (/tmp/jprt/P1/B/225621.kvn/source/src/share/vm/memory/allocation.cpp:84), pid=23844, tid=11
        # assert(allocated_on_res_area() || allocated_on_C_heap() || allocated_on_arena()) failed: allocation_type should be set by operator new()
        #
        # JRE version: 7.0
        # Java VM: OpenJDK 64-Bit Server VM (19.0-b04-201008032256.kvn.6973963-fastdebug compiled mode solaris-sparc compressed oops)
        # If you would like to submit a bug report, please visit:
        # http://java.sun.com/webapps/bugreport/crash.jsp
        #

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

        Current thread (0x00000001005b5800): JavaThread "CompilerThread0" daemon [_thread_in_native, id=11, stack(0xffffffff61300000,0xffffffff61400000)]

        Stack: [0xffffffff61300000,0xffffffff61400000], sp=0xffffffff613fb4d0, free space=1005k
        Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
        V [libjvm.so+0xef8d54];; __1cHVMErrorOreport_and_die6M_v_+0x6e4
        V [libjvm.so+0x51cfb0];; __1cPreport_vm_error6Fpkci11_v_+0x78
        V [libjvm.so+0x26f674];; __1cLResourceObj2t6M_v_+0x9c
        V [libjvm.so+0x298fe4];; __1cRAbstractAssembler2t6MpnKCodeBuffer__v_+0x34
        V [libjvm.so+0x18b2f0];; __1cPemit_call_reloc6FrnKCodeBuffer_lnJrelocInfoJrelocType_bb_v_+0x48
        V [libjvm.so+0x1be6d8];; __1cZCallDynamicJavaDirectNodeEemit6kMrnKCodeBuffer_pnNPhaseRegAlloc__v_+0x200
        V [libjvm.so+0xc16598];; __1cHCompileLFill_buffer6M_v_+0xd50
        V [libjvm.so+0x46fa14];; __1cHCompileICode_Gen6M_v_+0x400
        V [libjvm.so+0x469e40];; __1cHCompile2t6MpnFciEnv_pnKC2Compiler_pnIciMethod_ibb_v_+0xda8
        V [libjvm.so+0x31a3cc];; __1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_+0xb4
        V [libjvm.so+0x47da14];; __1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_+0xe5c
        V [libjvm.so+0x47c5e0];; __1cNCompileBrokerUcompiler_thread_loop6F_v_+0x960
        V [libjvm.so+0xe46f34];; __1cKJavaThreadRthread_main_inner6M_v_+0x174
        V [libjvm.so+0xe46da0];; __1cKJavaThreadDrun6M_v_+0x310
        V [libjvm.so+0xbfbfc4];; java_start+0x184

        Current CompileTask:
        C2: 94 b java.util.HashMap.get(Ljava/lang/Object;)Ljava/lang/Object; (79 bytes)

        -------------------------------------------------------------------------
        The assert is from my fix for 6973963. And I can't reproduce the failure.

        It could be because ~ResourceObj() is not called for _masm allocated on stack, which I doubt:

        void emit_call_reloc() {
          MacroAssembler _masm(&cbuf); <<< Allocation on stack.
        ...
        }

        Most likely it is because the garbage value on stack is equal to ~(address of _masm on stack).
        For example, for 0xffffffff613fb4d0 (sp from hs_err file) it should be 0x9ec04b20.
        I thought it would be impossible but, it seems, I was wrong.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                kvn Vladimir Kozlov
                Reporter:
                kvn Vladimir Kozlov
                Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: