JDK-7033141 : assert(has_cp_cache(i)) failed: oob
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs19,hs21,6u20,6u24
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux_ubuntu
  • CPU: generic,x86
  • Submitted: 2011-04-01
  • Updated: 2020-06-17
  • Resolved: 2011-07-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7Fixed 8Fixed hs21Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
Application crashes with assert (JDK 7 b136, HS 21 b06, -server -d64 -XX:-UseCompressedOops -XX:+UseParallelGC -XX:+UseParallelOldGC -Xcomp -XX:CompileThreshold=1 -XX:+UseCodeCacheFlushing)

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/export/HUDSON/workspace/jdk7-2-build-solaris-amd64-product/jdk7/hotspot/src/share/vm/interpreter/rewriter.hpp:50), pid=3699, tid=250
#  assert(has_cp_cache(i)) failed: oob
#
# JRE version: 7.0-b136
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b06-fastdebug compiled mode solaris-amd64 )

Current thread (0x00000000045e7000):  JavaThread "Thread-26" [_thread_in_vm, id=250, stack(0xfffffd7ffb774000,0xfffffd7ffb874000)]

Stack: [0xfffffd7ffb774000,0xfffffd7ffb874000],  sp=0xfffffd7ffb86df70,  free space=999k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x25e8c9e]  void VMError::report(outputStream*)+0x8c6;;  void VMError::report(outputStream*)+0x8c6
V  [libjvm.so+0x25e9ddd]  void VMError::report_and_die()+0x4fd;;  void VMError::report_and_die()+0x4fd
V  [libjvm.so+0xe2f723]  void report_vm_error(const char*,int,const char*,const char*)+0x55f;;  void report_vm_error(const char*,int,const char*,const char*)+0x55f
V  [libjvm.so+0x226bb3d]  void Rewriter::scan_method(methodOop)+0xdc5;;  void Rewriter::scan_method(methodOop)+0xdc5
V  [libjvm.so+0x226df24]  Rewriter::Rewriter #Nvariant 1(instanceKlassHandle,constantPoolHandle,objArrayHandle,Thread*)+0xe50;;  Rewriter::Rewriter(instanceKlassHandle,constantPoolHandle,objArrayHandle,Thread*)+0xe50
V  [libjvm.so+0x226cc14]  void Rewriter::rewrite(instanceKlassHandle,Thread*)+0x940;;  void Rewriter::rewrite(instanceKlassHandle,Thread*)+0x940
V  [libjvm.so+0x11896c4]  void instanceKlass::rewrite_class(Thread*)+0x54c;;  void instanceKlass::rewrite_class(Thread*)+0x54c
V  [libjvm.so+0x1188468]  bool instanceKlass::link_class_impl(instanceKlassHandle,bool,Thread*)+0x19c4;;  bool instanceKlass::link_class_impl(instanceKlassHandle,bool,Thread*)+0x19c4
V  [libjvm.so+0x11864a9]  void instanceKlass::link_class(Thread*)+0x375;;  void instanceKlass::link_class(Thread*)+0x375
V  [libjvm.so+0x11899d0]  void instanceKlass::initialize_impl(instanceKlassHandle,Thread*)+0xec;;  void instanceKlass::initialize_impl(instanceKlassHandle,Thread*)+0xec
V  [libjvm.so+0x1185eac]  void instanceKlass::initialize(Thread*)+0x38c;;  void instanceKlass::initialize(Thread*)+0x38c
V  [libjvm.so+0xf6919c]  Handle Exceptions::new_exception(Thread*,Symbol*,Symbol*,JavaCallArguments*,Handle,Handle,Handle)+0x588;;  Handle Exceptions::new_exception(Thread*,Symbol*,Symbol*,JavaCallArguments*,Handle,Handle,Handle)+0x588
V  [libjvm.so+0xf67397]  void Exceptions::_throw_args(Thread*,const char*,int,Symbol*,Symbol*,JavaCallArguments*)+0x92b;;  void Exceptions::_throw_args(Thread*,const char*,int,Symbol*,Symbol*,JavaCallArguments*)+0x92b
V  [libjvm.so+0x221911c]  oop Reflection::invoke(instanceKlassHandle,methodHandle,Handle,bool,objArrayHandle,BasicType,objArrayHandle,bool,Thread*)+0x31f4;;  oop Reflection::invoke(instanceKlassHandle,methodHandle,Handle,bool,objArrayHandle,BasicType,objArrayHandle,bool,Thread*)+0x31f4
V  [libjvm.so+0x2230e01]  oop Reflection::invoke_method(oop,Handle,objArrayHandle,Thread*)+0xdd5;;  oop Reflection::invoke_method(oop,Handle,objArrayHandle,Thread*)+0xdd5
V  [libjvm.so+0x17a87be]  JVM_InvokeMethod+0xae2;;  JVM_InvokeMethod+0xae2
C  [libjava.so+0x1ae16]  Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x12;;  Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x12
J  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
J  sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
J  sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
J  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
J  bigapps.dacapo.DacapoRunner$BenchmarkRunner.run()V
J  java.lang.Thread.run()V
v  ~StubRoutines::call_stub
-

Comments
In latest repo: http://hg.openjdk.java.net/jdk/jdk/rev/d496ecd7b9de
17-06-2020

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2d4b2b833d29
09-06-2011

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d3b9f2be46ab
09-06-2011

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2d4b2b833d29
28-05-2011

EVALUATION Summary: Unrewrite bytecodes for OOM error allocating the constant pool cache. Reviewed-by: dcubed, acorn, never (I marked this fix-available but didn't change target release).
23-05-2011

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d3b9f2be46ab
22-05-2011

EVALUATION If the VM runs out of permgen space while allocating the constant pool cache, it tries to reverify the bytecodes in the methods for the class. But the bytecodes have been rewritten. I'm working on a fix that un-rewrites the bytecodes so that the VM can try again to link this class. I am debugging this now - actually I'm debugging my code that forces the error condition (for testing) since this but only reproduces for a specific error condition. It's not very unlikely for an application to run out of permgen (or code cache as in bug 6947901) so it is probably worth fixing for jdk 7. The fix is relatively low risk once it's debugged.
17-05-2011