JDK-8236746 : SEGV in TreeList >::remove_chunk_replace_if_needed(TreeChunk >*)+0x4
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2020-01-08
  • Updated: 2025-04-17
  • Resolved: 2020-02-07
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 15
15Resolved
Related Reports
Duplicate :  
JDK-8236743 - JFR: assert(klass != __null) failed: invariant in ObjectSampleCheckpoint::add_to_leakp_set
Description
Stress test crashes with

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fc77fcd7a74, pid=1715, tid=1780
#
# JRE version: Java(TM) SE Runtime Environment (14.0+31) (build 14-ea+31-1396)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14-ea+31-1396, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x3eda74]  TreeList<metaspace::Metablock, FreeList<metaspace::Metablock> >::remove_chunk_replace_if_needed(TreeChunk<metaspace::Metablock, FreeList<metaspace::Metablock> >*)+0x4
#
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/6e54f4af-e606-43b0-80ce-0a482a5988b6-S260/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2115d087-19ee-47c8-b0a4-bb0deaf4998b/runs/d346b3e5-8da8-4778-885f-77c7d48a40f1/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/core.1715)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:MaxRAMPercentage=6 -Dkitchensink.modules.additional=Instrumentation -XX:MaxRAMPercentage=50 -XX:MaxMetaspaceSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false -XX:+DisplayVMOutputToStderr -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags -XX:+DisableExplicitGC -XX:+StartAttachListener --add-exports=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/6e54f4af-e606-43b0-80ce-0a482a5988b6-S260/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2115d087-19ee-47c8-b0a4-bb0deaf4998b/runs/d346b3e5-8da8-4778-885f-77c7d48a40f1/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/java.io.tmpdir -Duser.home=/opt/mach5/mesos/work_dir/slaves/6e54f4af-e606-43b0-80ce-0a482a5988b6-S260/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2115d087-19ee-47c8-b0a4-bb0deaf4998b/runs/d346b3e5-8da8-4778-885f-77c7d48a40f1/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/user.home -agentpath:/opt/mach5/mesos/work_dir/jib-master/install/jdk-14+31-1396/linux-x64.test/hotspot/jtreg/native/libJvmtiStressModule.so -XX:NativeMemoryTracking=detail -Xverify:all -javaagent:redefineagent.jar applications.kitchensink.process.stress.Main /opt/mach5/mesos/work_dir/slaves/6e54f4af-e606-43b0-80ce-0a482a5988b6-S260/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2115d087-19ee-47c8-b0a4-bb0deaf4998b/runs/d346b3e5-8da8-4778-885f-77c7d48a40f1/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java/scratch/0/kitchensink.final.properties

Host: Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz, 8 cores, 58G, Oracle Linux Server release 7.6
Time: Wed Jan  8 01:14:31 2020 UTC elapsed time: 127 seconds (0d 0h 2m 7s)

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

Current thread (0x00007fc77850b000):  JavaThread "InstrumentationStressModule" [_thread_in_vm, id=1780, stack(0x00007fc6b34f5000,0x00007fc6b35f6000)]

Stack: [0x00007fc6b34f5000,0x00007fc6b35f6000],  sp=0x00007fc6b35f3678,  free space=1017k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x3eda74]  TreeList<metaspace::Metablock, FreeList<metaspace::Metablock> >::remove_chunk_replace_if_needed(TreeChunk<metaspace::Metablock, FreeList<metaspace::Metablock> >*)+0x4
V  [libjvm.so+0x3ed50b]  metaspace::BlockFreelist::get_block(unsigned long)+0xab
V  [libjvm.so+0xc053b3]  metaspace::SpaceManager::allocate(unsigned long)+0xf3
V  [libjvm.so+0xa9fd88]  Metaspace::allocate(ClassLoaderData*, unsigned long, MetaspaceObj::Type, Thread*)+0x58
V  [libjvm.so+0xab0d9d]  Method::allocate(ClassLoaderData*, int, AccessFlags, InlineTableSizes*, ConstMethod::MethodType, Thread*)+0x5d
V  [libjvm.so+0x505be6]  ClassFileParser::parse_method(ClassFileStream const*, bool, ConstantPool const*, AccessFlags*, Thread*)+0xdd6
V  [libjvm.so+0x506e79]  ClassFileParser::parse_methods(ClassFileStream const*, bool, AccessFlags*, bool*, bool*, Thread*)+0x1d9
V  [libjvm.so+0x5094bb]  ClassFileParser::parse_stream(ClassFileStream const*, Thread*) [clone .part.198]+0x64b
V  [libjvm.so+0x50c0e6]  ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, Handle, InstanceKlass const*, GrowableArray<Handle>*, ClassFileParser::Publicity, Thread*)+0x316
V  [libjvm.so+0x97623b]  KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, Handle, InstanceKlass const*, GrowableArray<Handle>*, Thread*)+0x10b
V  [libjvm.so+0xc7b39c]  SystemDictionary::parse_stream(Symbol*, Handle, Handle, ClassFileStream*, InstanceKlass const*, GrowableArray<Handle>*, Thread*)+0x1dc
V  [libjvm.so+0x9620cb]  VM_RedefineClasses::load_new_class_versions(Thread*) [clone .part.122]+0x27b
V  [libjvm.so+0x963392]  VM_RedefineClasses::doit_prologue()+0x1b2
V  [libjvm.so+0xd389d4]  VMThread::execute(VM_Operation*)+0x54
V  [libjvm.so+0x9316a9]  JvmtiEnv::RetransformClasses(int, _jclass* const*)+0x269
V  [libjvm.so+0x8f0bbe]  jvmti_RetransformClasses+0x10e
C  [libinstrument.so+0x4c56]  retransformClasses+0x1b6
j  sun.instrument.InstrumentationImpl.retransformClasses0(J[Ljava/lang/Class;)V+0 java.instrument@14-ea
j  sun.instrument.InstrumentationImpl.retransformClasses([Ljava/lang/Class;)V+29 java.instrument@14-ea
j  applications.kitchensink.process.stress.modules.InstrumentationStressModule.execute()V+111
j  applications.kitchensink.process.stress.modules.StressModule.run()V+109
v  ~StubRoutines::call_stub
V  [libjvm.so+0x78d6bb]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x2fb
V  [libjvm.so+0x78d999]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x179
V  [libjvm.so+0x78da61]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0x81
V  [libjvm.so+0x83519c]  thread_entry(JavaThread*, Thread*)+0x6c
V  [libjvm.so+0xcc44f2]  JavaThread::thread_main_inner()+0xe2
V  [libjvm.so+0xcc8d0d]  Thread::call_run()+0x10d
V  [libjvm.so+0xb26437]  thread_native_entry(Thread*)+0xe7

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.instrument.InstrumentationImpl.retransformClasses0(J[Ljava/lang/Class;)V+0 java.instrument@14-ea
j  sun.instrument.InstrumentationImpl.retransformClasses([Ljava/lang/Class;)V+29 java.instrument@14-ea
j  applications.kitchensink.process.stress.modules.InstrumentationStressModule.execute()V+111
j  applications.kitchensink.process.stress.modules.StressModule.run()V+109
v  ~StubRoutines::call_stub
Comments
The results of running this test with this build ( jdk-14+31-1396) shows all kinds of crashes not present today. These crashes, including this one, are because of corrupted Metaspace. The binaryDictionary TreeChunks are a free list of metaspace blocks and are allocated in-place in metaspace. It appears that JDK-8236743 can corrupt Metaspace with redefinition by incorrectly tracking Methods that aren't kept alive. Closing this as a duplicate.
07-02-2020
This build-id looks massively broken. I get lots of crashes with the reproducer command line. I can't reproduce this with the current JDK 15 repository. I also cannot reproduce this with the JDK 14 repository, either product or fastdebug.
06-02-2020
Not sure if that helps, but if the core file is no use, you could at least make the metaspace report in the hs-err file a bit more verbose by: --- a/src/hotspot/share/utilities/vmError.cpp Sat Feb 01 09:55:03 2020 +0100 +++ b/src/hotspot/share/utilities/vmError.cpp Thu Feb 06 19:25:11 2020 +0100 @@ -926,7 +926,8 @@ if (_verbose && Universe::is_fully_initialized()) { st->print_cr("Metaspace:"); - MetaspaceUtils::print_basic_report(st, 0); + MetaspaceUtils::print_report(st); + } STEP("printing code cache information") That would show you the number of deallocated blocks and their size (so, the tree dictionary population).
06-02-2020
ILW = HLM = P3
14-01-2020