JDK-8040237 : nsk/jvmti/RetransformClasses/retransform001 crashed the VM on all platforms when run with with -server -Xcomp
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-04-15
  • Updated: 2018-10-02
  • Resolved: 2014-07-11
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 9
9 b25Fixed
Related Reports
Duplicate :  
JDK-8211392 - compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI
Relates :  
JDK-8038636 - speculative traps break when classes are redefined
Description
The test crashed the VM on all platforms in PIT JDK9_b08 (product build, flags: -server -Xcomp)

The crash is SIGBUS on solaris-sparc, EXCEPTION_ACCESS_VIOLATION on windows and SIGSEGV on linux and solaris-amd64

The log is similar on all platforms:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xf701ffec, pid=3521, tid=2753559408
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-201404111842.amurillo.jdk9-hs-2014-04-11-b00)
# Java VM: Java HotSpot(TM) Server VM (25.0-b62 compiled mode linux-x86 )
# Problematic frame:
# V  [libjvm.so+0x6cffec]  CleanExtraDataMethodClosure::is_live(Method*)+0xc
#
# 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
#

There is a core file in the solaris-sparc result directory.

Priority justification:
Impact = High: Crash
Likelihood = Low: Only when -server -Xcomp is specified (yet)
Workaround = High, only workaround is not using those flags

ILW = HLH => P2

RULE nsk/jvmti/RetransformClasses/retransform001 Crash SIGBUS
RULE nsk/jvmti/RetransformClasses/retransform001 Crash EXCEPTION_ACCESS_VIOLATION
RULE nsk/jvmti/RetransformClasses/retransform001 Crash SIGSEGV
Comments
InstanceKlass::purge_previous_versions() is called on every classes of a class loader from ClassLoaderDataGraph::do_unloading() right before free_deallocate_list() for that class loader. Every reference to a method not on_stack() in the MDO is removed. The following call to free_deallocate_list() frees methods that are not on_stack() for that class loader. Every method that is on_stack() is not freed and references to that method are left as is. The crash happens because one method���s MDO can reference another method in another class loader. When that happens, the loop in ClassLoaderDataGraph::do_unloading() may call free_deallocate_list() and free redefined method m1 that is not on stack and a subsequent iteration will go over method m2's MDO that references m1 that is gone. This is fixed by first calling InstanceKlass::purge_previous_versions() on every class of every class loaders in case of class redefinition first and then only iterating again on all class loader data to free metadata.
10-07-2014
Reassiging to Roland // Check for entries that reference a redefined method class CleanExtraDataMethodClosure : public CleanExtraDataClosure { public: CleanExtraDataMethodClosure() {} bool is_live(Method* m) { return m->on_stack(); } }; on_stack() doesn't mean it's been redefined. is_old() and !on_stack() means it's likely that references to it can be deleted. The stack for fastdebug asserts with the on_stack() call so it looks like the Method* pointer is bad.
20-05-2014
This crash is because of code added for this bug. I don't see why clean_weak_method_links are called for new methods. I can reproduce this with fastdebug.
20-05-2014
Stack: [0xfffffd7f8abf0000,0xfffffd7f8acf0000], sp=0xfffffd7f8aceea18, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x10dd4de] bool CleanExtraDataMethodClosure::is_live(Method*)+0xe V [libjvm.so+0xc15f2a] void InstanceKlass::purge_previous_versions(InstanceKlass*)+0x822 V [libjvm.so+0x92a976] bool ClassLoaderDataGraph::do_unloading(BoolObjectClosure*)+0x19a V [libjvm.so+0x132cfe3] bool SystemDictionary::do_unloading(BoolObjectClosure*)+0xf V [libjvm.so+0x1217608] void PSParallelCompact::marking_phase(ParCompactionManager*,bool,ParallelOldTracer*)+0x50c V [libjvm.so+0x1215269] void PSParallelCompact::invoke(bool)+0x8c9 V [libjvm.so+0x9498fa] void CollectedHeap::collect_as_vm_thread(GCCause::Cause)+0xd6 V [libjvm.so+0x144f9cb] void VM_CollectForMetadataAllocation::doit()+0x117 V [libjvm.so+0x1457ced] void VM_Operation::evaluate()+0x81 V [libjvm.so+0x1455ee8] void VMThread::loop()+0x4e4 V [libjvm.so+0x14554b3] void VMThread::run()+0x7b V [libjvm.so+0x11798d7] java_start+0x217 C [libc.so.1+0xd704b] _thr_setup+0x5b C [libc.so.1+0xd7280] _lwp_start+0x0
06-05-2014