JDK-6272221 : assertion failure in ContiguousSpace::block_size after massive number of RedefineClasses
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris
  • CPU: generic,sparc
  • Submitted: 2005-05-18
  • Updated: 2012-02-01
  • Resolved: 2006-04-04
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.
Other JDK 6
5.0u8Fixed 6 b79Fixed
Related Reports
Duplicate :  
JDK-6359123 - Stress tests, related to classloading, fail with assertion on solaris-sparc fastdebug build
Relates :  
JDK-6394084 - Redefine class can't handle addition of 64 bit constants in JDK1.5.0_04
Relates :  
JDK-6393258 - crash: redefine classes method order change incomplete
Relates :  
JDK-5088035 - hotswap fires assert(0 <= i && i < length(),"index out of bounds")
Description
During a test that redefines hundreds of classes a jvmg build asserts with:

#  Internal Error (/net/producer/export2/rfield/p1/src/share/vm/memory/space.cpp, 674 [ Patched ]), pid=6211, tid=2

# Error: assert(p == current_top || oop(p)->is_oop(),"p is not a block start")


###@###.### 2005-05-18 06:04:51 GMT
Does this affect tests below?  Please let me know and we can remove this from the description (didn't put nsk_testbase keyword in yet).  Don't we want the automatic vm.knownbugs tool to pick these up?  Thanks.

runtime/ParallelClassLoading/stress-redefine/freeLock/forName/dynamic-init/init-complex
runtime/ParallelClassLoading/stress-redefine/freeLock/forName/init-complex
runtime/ParallelClassLoading/stress-redefine/freeLock/loadClass/dynamic-init/init-complex
runtime/ParallelClassLoading/stress-redefine/holdLock/forName/dynamic-init/init-complex
runtime/ParallelClassLoading/stress-redefine/holdLock/forName/init-complex
runtime/ParallelClassLoading/stress-redefine/holdLock/forName/tree
runtime/ParallelClassLoading/stress-redefine/holdLock/loadClass/dynamic-init/init-complex
runtime/ParallelClassLoading/stress-redefine/holdLock/loadClass/tree
A number of new tests(will be introduced since r05) fail with the same assertion:
runtime/ParallelClassLoading/mixed/systemloader/forName/anonymous-complex
runtime/ParallelClassLoading/mixed/systemloader/forName/anonymous-simple
runtime/ParallelClassLoading/mixed/systemloader/forName/dynamic-init/anonymous-complex
runtime/ParallelClassLoading/mixed/systemloader/forName/dynamic-init/anonymous-simple
runtime/ParallelClassLoading/mixed/systemloader/loadClass/anonymous-complex
runtime/ParallelClassLoading/mixed/systemloader/loadClass/anonymous-simple
runtime/ParallelClassLoading/mixed/systemloader/loadClass/dynamic-init/anonymous-complex
runtime/ParallelClassLoading/mixed/systemloader/loadClass/dynamic-init/anonymous-simple
runtime/ParallelClassLoading/stress-redefine/freeLock/reflect/init-complex
runtime/ParallelClassLoading/stress-redefine/holdLock/reflect/init-complex
Comments
SUGGESTED FIX Please see the attached 6272221-6394084-webrev-cr1-full.tgz file for the full version of the proposed fix after one round of code review. Please see the attached 6272221-6394084-webrev-cr1-delta.tgz for the "delta only" diffs relative to code review round 0.
27-03-2006
SUGGESTED FIX Please see the attached 6272221-6394084-webrev-cr0.tgz file for the proposed fix.
23-03-2006
EVALUATION For the test script from 6359123, the constantPoolOopDesc._tags field gets overwritten by a JVM_CONSTANT_Double entry appended to the constant pool by RedefineClasses(). It turns out that constant pool merging for JVM_CONSTANT_Double and JVM_CONSTANT_Long entries works mostly by accident. JVM_CONSTANT_Double and JVM_CONSTANT_Long entries occupy two constant pool entries and all other constant pool entry types occupy one constant pool entry. If a JVM_CONSTANT_Double or JVM_CONSTANT_Long is the last entry appended to a constant pool during the merging process, then the last four bytes of the double or long value go right off the end and clobber the constantPoolOopDesc._tags field.
23-03-2006
EVALUATION For the test script from 6359123, the bad oop is supposed to be the constantPoolOopDesc._tags field in a class that we redefined. This isn't an oop referring to something that we threw away; this oop is supposed to be alive. I don't know what overwrote the mark word yet, but that's what went wrong.
22-03-2006