United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6975078 assert(allocated_on_res_area() || allocated_on_C_heap() || allocated_on_arena()
JDK-6975078 : assert(allocated_on_res_area() || allocated_on_C_heap() || allocated_on_arena()

Details
Type:
Bug
Submit Date:
2010-08-05
Status:
Closed
Updated Date:
2011-04-23
Project Name:
JDK
Resolved Date:
2011-04-23
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
hs19
Fixed Versions:
hs19 (b06)

Related Reports
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:

Sub Tasks

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.

                                    

Comments
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2dfd013a7465
                                     
2010-08-10
PUBLIC COMMENTS

The assert is from my fix for 6973963 and I can't reproduce this failure.
void emit_call_reloc() {
  MacroAssembler _masm(&cbuf); <<< asserts here, allocation on stack.

It could be because ~ResourceObj() destructor is not called for
_masm but I doubt it. In 6973963 changes to track correctness of
allocation type (to separate it from garbage on stack) I encoded
(negated) 'this' address into _allocation value and zap it in
~ResourceObj() destructor.

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 could be 0x9ec04b20.
I thought it would be impossible but I was wrong, it seems.

Solution:
Pass the check in constructor ResourceObj() if _allocation has
a value which looks like an allocation on stack and it is really
allocated on stack.
                                     
2010-08-10
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2dfd013a7465
                                     
2010-08-14



Hardware and Software, Engineered to Work Together