JDK-8013063 : nsk/jvmti/RetransformClasses/retransform001 failed debug version on os::free
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2013-04-23
  • Updated: 2017-10-02
  • Resolved: 2013-05-08
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 8 Other
8Fixed hs25Fixed
Related Reports
Relates :  
JDK-8008453 - JvmtiClassFileReconstituter does not recognize default methods
Relates :  
JDK-7124706 - enable RetransformBigClass.sh test when fix for 8013063 is promoted
Relates :  
JDK-8178870 - instrumentation.retransformClasses cause coredump
Relates :  
JDK-8014024 - NPG: keep compiled ic methods from being deallocated in redefine classes
Description
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/HUDSON/workspace/2-build-linux-i586/jdk8/4052/hotspot/src/share/vm/runtime/os.cpp:553), pid=827, tid=3175086960
#  fatal error: memory stomping error
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b86) (build 1.8.0-ea-fastdebug-b86)
# Java VM: Java HotSpot(TM) Server VM (25.0-b28-fastdebug mixed mode linux-x86 )
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

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

Current thread (0xbd5ba800):  VMThread [stack: 0xbd37f000,0xbd400000] [id=846]

Stack: [0xbd37f000,0xbd400000],  sp=0xbd3fe500,  free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xc276ce]  VMError::report_and_die()+0x1ae
V  [libjvm.so+0x574e3b]  report_fatal(char const*, int, char const*)+0x6b
V  [libjvm.so+0xa14c2f]  verify_block(void*)+0xaf
V  [libjvm.so+0xa15ea8]  os::free(void*, unsigned short)+0x78
V  [libjvm.so+0x700ece]  InstanceKlass::release_C_heap_structures()+0x37e
V  [libjvm.so+0x70d6e3]  InstanceKlass::deallocate_contents(ClassLoaderData*)+0x63
V  [libjvm.so+0x4b0b4d]  ClassLoaderData::free_deallocate_list()+0x31d
V  [libjvm.so+0x4b3aa7]  ClassLoaderDataGraph::do_unloading(BoolObjectClosure*)+0x1e7
V  [libjvm.so+0xb7dc5f]  SystemDictionary::do_unloading(BoolObjectClosure*)+0x1f
V  [libjvm.so+0xa9b96b]  PSParallelCompact::marking_phase(ParCompactionManager*, bool)+0x3cb
V  [libjvm.so+0xaa3c25]  PSParallelCompact::invoke_no_policy(bool)+0x495
V  [libjvm.so+0xaa4a7c]  PSParallelCompact::invoke(bool)+0xdc
V  [libjvm.so+0x4d8e99]  CollectedHeap::collect_as_vm_thread(GCCause::Cause)+0x199
V  [libjvm.so+0xc28c9d]  VM_CollectForMetadataAllocation::doit()+0x1bd
V  [libjvm.so+0xc53c82]  VM_Operation::evaluate()+0x82
V  [libjvm.so+0xc50b0d]  VMThread::evaluate_operation(VM_Operation*)+0xad
V  [libjvm.so+0xc5216a]  VMThread::loop()+0x65a
V  [libjvm.so+0xc523e1]  VMThread::run()+0xc1
V  [libjvm.so+0xa21519]  java_start(Thread*)+0x119
C  [libpthread.so.0+0x69e9]  abort@@GLIBC_2.0+0x69e9
Comments
Staffan's fix for 8008453 with jdk8-b80 fixes the method != NULL crash (but not the stomping error). So this reverts back to my bug.
02-05-2013
With jdk8-b87, the isAnnotationPresent default method is gone so this reverts to the original crash in os::free. So there are two bugs, I think.
02-05-2013
I don't think jdk7 vs. jdk8 version of the redefined java/lang/Class is the problem, even with jdk8 the redefined class doesn't have the default method. So it seems that filling in the vtable for the redefined class is a problem with default methods.
29-04-2013
In debug mode with -noverify, this test and the other that seems to be a duplicate test gets this assertion: # Internal Error (/java/east/u1/cphillim/hg/rt.stomp/src/share/vm/oops/klassVtable.hpp:163), pid=17281, tid=140051249350400 # assert(method != NULL) failed: use clear # The test redefines java/lang/Class, the new version that it redefines it to doesn't match the old version in the code. The reason it doesn't match is because there are default methods inserted in the vtable for the old version (based on jdk8) and the "new" version of the class is based on jdk7 which doesn't have default methods. Based on -XX:+PrintVtables -XX:+Verbose Initial version: Initializing: java/lang/Class copy vtable from java.lang.Object to java.lang.Class size 6 adding java.lang.Class::toString at index 2 overriding with java.lang.Class::toString index 2, original flags: public overriders flags: public adding java.lang.Class::isAnnotationPresent at index 5 "New" version that redefine classes barfs on because there is no isAnnotationPresent in the classfile for java/lang/Class that it uses for the redefinition. Initializing: java/lang/Class copy vtable from java.lang.Object to java.lang.Class size 6 adding java.lang.Class::toString at index 2 overriding with java.lang.Class::toString index 2, original flags: public overriders flags: public adding java.lang.Class::<NULL> at index 5 isAnnotationPresent is a default method so isn't checked in compare_and_normalize_class_versions. Need to make this long function even longer. I don't know why this later stomps or if it stomps if a jdk8 version of the redefinition is used.
29-04-2013
I'm getting Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad class index from the test so I think the version I have is wrong, can you send me the version of TESTBASE that you are using?
23-04-2013
Can you attach the rerun.sh script? I can't reproduce this yet. thanks.
23-04-2013
Several bugs have been filed with crashes where InstanceKlass::release_C_heap_structures() is in the stack: JDK-8011899 nsk/jvmti/IterateThroughHeap/callbacks crashes intermittently in ConstantPool::release_C_heap_structures() JDK-8012976 JVM crash in javac by using javaagent for code coverage. JDK-8013063 nsk/jvmti/RetransformClasses/retransform001 failed debug version on os::free JDK-8011899 is closed as a duplicate of: INTJDK-7603110 The JVMTI test nsk/jvmti/IterateThroughHeap/callbacks has a race condition So it makes me wonder if these other recent release_C_heap_structures() are related.
23-04-2013
reproduce with the version in description: create a file named: failedlist, put following line in it: nsk/jvmti/RetransformClasses/retransform001 execute_positive quick,jpda,jvmti,noras,feature_jdk6_jpda,vm6 then run runnsk -server -jdk $jdk -o <your result dir> failedlist
23-04-2013
It's a crash that wasn't there before.
23-04-2013