JDK-8243197 : Crash in oopDesc::size_given_klass
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 15,16
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: windows
  • CPU: x86_64
  • Submitted: 2020-04-20
  • Updated: 2020-11-30
  • Resolved: 2020-11-30
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 16
16Resolved
Related Reports
Duplicate :  
JDK-8256641 - CDS VM operations do not lock the heap
Duplicate :  
JDK-8256144 - runtime/cds/appcds/dynamicArchive/DynamicLotsOfClasses.java failed with EXCEPTION_ACCESS_VIOLATION in oopDesc::size_given_klass
Relates :  
JDK-8248447 - SIGSEGV in G1ScanHRForRegionClosure::scan_heap_roots
Description
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff8dc349e46, pid=10792, tid=6692
#
# JRE version: Java(TM) SE Runtime Environment (15.0) (build 15-internal+0-2020-04-18-0647519.mikael.vidstedt.jdk)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (15-internal+0-2020-04-18-0647519.mikael.vidstedt.jdk, mixed mode, tiered, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0x169e46]  oopDesc::size_given_klass+0x6
#
# Core dump will be written. Default location: T:\\testoutput\\test-support\\jtreg_closed_test_hotspot_jtreg_applications_dacapo_Dacapo24H_java\\scratch\\0\\hs_err_pid10792.mdmp
#
Unsupported internal testing APIs have been used.

# An error report file with more information is saved as:
# T:\\testoutput\\test-support\\jtreg_closed_test_hotspot_jtreg_applications_dacapo_Dacapo24H_java\\scratch\\0\\hs_err_pid10792.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
Comments
I suspect this bug has the same root cause as JDK-8256641. Closing as a duplicate thereof.
30-11-2020
[~iklam]: can you please refile this issue with the latest information about the subject of this CR. This issue looks like a dumping ground for various crashes caused by bad (klass?) pointers, has actually been closed once and then reopened to be used with a completely seemingly different issue. Looking at bug history in the CI, even jdk13(!) bugs are assigned to it. A bad (klass?) pointer can be caused by lots of reasons, just gc happening to be the first reading the pointer. Did you also try reproducing with -XX:+VerifyBefore/AfterGC? Such issues are very confusing to work with otherwise. Thanks.
20-11-2020
Another crash has references to a value above the top of a region: RCX=0x00000000d0be85d0 Heap region: | 11|0x00000000d0b00000, 0x00000000d0b846b0, 0x00000000d0c00000| 51%| E|CS|TAMS 0x00000000d0b00000, 0x00000000d0b00000| Complete
19-11-2020
In one of the crashes there's also references to this address: RBX=0x00000000fff00000 Top of Stack: (sp=0x000000db4d9ff750) 0x000000db4d9ff750: 00000000fff00000 00007fff58f59712 Which is the last heap region | 499|0x00000000fff00000, 0x00000000fff00800, 0x0000000100000000| 0%| E| |TAMS 0x00000000fff00000, 0x00000000fff00000| Complete Might be worth digging into.
19-11-2020
Note that the pattern you found corresponds to a decompressed broken pointer (0xbaadbabe): (gdb) p/x ((0x0000000dd56dd600ULL - 16) >> 3) - 0x100000000 $11 = 0xbaadbabe and there also a reference to the x - 16 value in one of the registers: RAX=0x0000000dd56dd5f0
19-11-2020
Interesting observation: we have a crash on the loom repo with jdk/jshell/T8146368/JShellToolTest8146368.java. So this is unrelated to CDS dynamic dumping: V [jvm.dll+0x2a9283] oopDesc::size_given_klass+0x23 (oop.inline.hpp:155) << crash V [jvm.dll+0x6d15c0] G1ParScanThreadState::do_copy_to_survivor_space+0xd0 (g1ParScanThreadState.cpp:443) V [jvm.dll+0x6cdaf3] G1ParScanThreadState::do_oop_evac<enum narrowOop>+0x273 (g1ParScanThreadState.cpp:208) V [jvm.dll+0x6d369e] G1ParScanThreadState::trim_queue_to_threshold+0x1ae (g1ParScanThreadState.cpp:310) V [jvm.dll+0x6cc37c] G1ParScanThreadState::trim_queue_partially+0x6c (g1ParScanThreadState.inline.hpp:52) V [jvm.dll+0x6e8c6f] G1ScanHRForRegionClosure::do_claimed_block+0x1df (g1RemSet.cpp:690) V [jvm.dll+0x6eb800] G1ScanHRForRegionClosure::scan_heap_roots+0x520 (g1RemSet.cpp:726) V [jvm.dll+0x6e9686] G1ScanHRForRegionClosure::do_heap_region+0x136 (g1RemSet.cpp:772) V [jvm.dll+0x6eb1d2] G1RemSet::scan_heap_roots+0x152 (g1RemSet.cpp:790) V [jvm.dll+0x68e402] G1EvacuateRegionsTask::scan_roots+0x62 (g1CollectedHeap.cpp:3805) V [jvm.dll+0x691281] G1EvacuateRegionsBaseTask::work+0x61 (g1CollectedHeap.cpp:3791) V [jvm.dll+0xe7a509] GangWorker::loop+0x89 (workgroup.cpp:279) siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000dd56dd600 <<<<<<< HERE But the failing address is exactly the same as runtime/cds/appcds/dynamicArchive/DynamicLotsOfClasses.java: V [jvm.dll+0x3429be] oopDesc::size_given_klass+0x1e (oop.inline.hpp:190) << crash V [jvm.dll+0x5cb971] HeapRegion::verify+0x131 (heapRegion.cpp:674) V [jvm.dll+0x546357] VerifyRegionClosure::do_heap_region+0x367 (g1HeapVerifier.cpp:406) V [jvm.dll+0x5cec6d] HeapRegionManager::par_iterate+0x15d (heapRegionManager.cpp:535) V [jvm.dll+0x547e37] G1ParVerifyTask::work+0x67 (g1HeapVerifier.cpp:456) V [jvm.dll+0xcae422] GangWorker::loop+0x92 (workgroup.cpp:349) siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000dd56dd600 <<<<<<< HERE This means as we are scanning all the objects on G1 region, we run into an invalid object whose Klass appears to be 0x0000000dd56dd600, in both cases. There's one more crash whose address is 0x0000019fae6dd600, with the same 6dd600 suffix. I suspect this bug is in the GC. Reassigning to GC team for evaluation.
18-11-2020
thread #7, stop reason = signal SIGSTOP frame #0: 0x00007fff57046236 libsystem_kernel.dylib`semaphore_wait_trap + 10 frame #1: 0x00000001098ae058 libjvm.dylib`OSXSemaphore::wait(this=0x00007f969e518368) at semaphore_bsd.cpp:63 [opt] frame #2: 0x0000000109b0767a libjvm.dylib`SemaphoreGangTaskDispatcher::coordinator_execute_on_workers(AbstractGangTask*, unsigned int, bool) [inlined] Semaphore::wait(this=<unavailable>) at semaphore.hpp:55 [opt] frame #3: 0x0000000109b07671 libjvm.dylib`SemaphoreGangTaskDispatcher::coordinator_execute_on_workers(this=0x00007f969e5182b0, task=0x00007000032653e0, num_workers=2, add_foreground_work=<unavailable>) at workgroup.cpp:149 [opt] frame #4: 0x0000000109b06a11 libjvm.dylib`WorkGang::run_task(this=0x00007f969e518240, task=0x00007000032653e0, num_workers=2, add_foreground_work=false) at workgroup.cpp:288 [opt] frame #5: 0x00000001090cacc1 libjvm.dylib`G1HeapVerifier::verify(this=0x00007f969e5100c0, vo=VerifyOption_Default) at g1HeapVerifier.cpp:513 [opt] frame #6: 0x0000000109a345b4 libjvm.dylib`Universe::verify(option=VerifyOption_Default, prefix=<unavailable>) at universe.cpp:1076 [opt] frame #7: 0x00000001090089ae libjvm.dylib`DynamicArchiveBuilder::verify_universe(char const*) [inlined] Universe::verify(prefix=<unavailable>) at universe.hpp:380 [opt] frame #8: 0x00000001090089a4 libjvm.dylib`DynamicArchiveBuilder::verify_universe(this=<unavailable>, info="Before CDS dynamic dump") at dynamicArchive.cpp:567 [opt] frame #9: 0x0000000109007af3 libjvm.dylib`DynamicArchiveBuilder::doit(this=0x000000010a469aa0) at dynamicArchive.cpp:572 [opt] frame #10: 0x0000000109007a45 libjvm.dylib`VM_PopulateDynamicDumpSharedSpace::doit(this=0x000000010a489b28) at dynamicArchive.cpp:1054 [opt] This crash is happening during dynamic archiver. GC threads are trying to verify the heap in parallel and one of the other threads finds the bad oop: (lldb) print *this (oopDesc) $2 = { _mark = (_value = 13451612990364039870) _metadata = { _klass = 0xbaadbabebaadbabe _compressed_klass = 3131947710 } } (lldb) print this (oopDesc *) $3 = 0x0000000132100000
12-08-2020
A crash in size_given_klass is sort of a generic bad oop crash. It looks like the recent incidents are not related to any GC bugs, and are all while verifying CDS dumping, and with MethodHandlesGeneralTest.java. This might relate to Lambda archiving. We can either take the bigapps-daCapo labels off and use this bug to track MethodHandleGeneralTest.java failures or close this as CNR (since it's unknown if it relates to JDK-8241804 or JDK-8248650).
16-07-2020
The above failure happened with runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesGeneralTest.java, but the crash happened before we start dumping the archive: [34.563s][info ][cds ] Verify Before CDS dynamic dump http://hg.openjdk.java.net/jdk/jdk/file/c969977b1702/src/hotspot/share/memory/dynamicArchive.cpp#l572
13-07-2020
Here's a snippet from the log file for the jdk-15+32-1517-tier8 failure: [34.400s][info ][class,load] java.lang.invoke.LambdaForm$MH/0x00000008012d2040 source: __JVM_LookupDefineClass__ [34.400s][debug][class,load] klass: 0x00000008012d2040 super: 0x0000000800007430 loader: [loader data: 0x00007f96a8767bf0 of 'bootstrap' has a class holder] bytes: 899 checksum: 1210b921 [34.408s][info ][class,load] java.lang.invoke.LambdaForm$MH/0x00000008012d2440 source: __JVM_LookupDefineClass__ [34.408s][debug][class,load] klass: 0x00000008012d2440 super: 0x0000000800007430 loader: [loader data: 0x00007f96a8688d20 of 'bootstrap' has a class holder] bytes: 1060 checksum: 41b94fea [34.415s][info ][class,load] com.sun.proxy.jdk.proxy1.$Proxy5 source: __dynamic_proxy__ [34.415s][debug][class,load] klass: 0x0000000801109048 super: 0x0000000800b7f360 interfaces: 0x0000000801108e30 0x0000000800b9b298 loader: [loader data: 0x00007f969e5f5b10 for instance a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x0000000122200d28}] bytes: 2660 checksum: 68033b9e [34.421s][info ][class,load] test.java.lang.invoke.MethodHandlesGeneralTest$PrivateRunnable source: file:/mesos/work_dir/slaves/52628e90-e5e7-4ef3-af97-10d8776d10db-S1975/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/6a99f9ae-2391-4da0-a1b6-cf038e86e9ed/runs/2246ffe5-0848-4d60-bd5b-5b312a18682b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/classes/1/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesGeneralTest.d/MH.jar [34.421s][debug][class,load] klass: 0x00000008011092a8 super: 0x0000000800007430 loader: [loader data: 0x00007f969e5f5b10 for instance a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x0000000122200d28}] bytes: 307 checksum: a87dde40 [34.427s][info ][class,load] java.util.stream.IntStream source: shared objects file [34.427s][debug][class,load] klass: 0x000000080020e5d8 super: 0x0000000800007430 interfaces: 0x00000008000f2118 loader: [loader data: 0x00007f969e711d60 of 'bootstrap'] [34.431s][info ][class,load] java.util.IdentityHashMap$IdentityHashMapIterator source: shared objects file [34.431s][debug][class,load] klass: 0x000000080031e148 super: 0x0000000800007430 interfaces: 0x000000080008a578 loader: [loader data: 0x00007f969e711d60 of 'bootstrap'] [34.443s][info ][class,load] java.util.IdentityHashMap$KeyIterator source: shared objects file [34.443s][debug][class,load] klass: 0x000000080031dec0 super: 0x000000080031e148 loader: [loader data: 0x00007f969e711d60 of 'bootstrap'] [34.510s][info ][class,load] java.lang.Shutdown source: shared objects file [34.510s][debug][class,load] klass: 0x0000000800047400 super: 0x0000000800007430 loader: [loader data: 0x00007f969e711d60 of 'bootstrap'] [34.552s][info ][class,load] java.lang.Shutdown$Lock source: shared objects file [34.552s][debug][class,load] klass: 0x0000000800364e28 super: 0x0000000800007430 loader: [loader data: 0x00007f969e711d60 of 'bootstrap'] [34.563s][info ][cds ] Verify Before CDS dynamic dump # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000108e1a657, pid=29224, tid=37123 # # JRE version: Java(TM) SE Runtime Environment (15.0+32) (fastdebug build 15-ea+32-1517) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-ea+32-1517, mixed mode, sharing, tiered, g1 gc, bsd-amd64) # Problematic frame: # V [libjvm.dylib+0x41a657] oopDesc::size_given_klass(Klass*)+0x17 # # Core dump will be written. Default location: core.29224 # # An error report file with more information is saved as: # /mesos/work_dir/slaves/52628e90-e5e7-4ef3-af97-10d8776d10db-S1975/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/6a99f9ae-2391-4da0-a1b6-cf038e86e9ed/runs/2246ffe5-0848-4d60-bd5b-5b312a18682b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/scratch/3/hs_err_pid29224.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # ]; stderr: [] exitValue = 134 JavaTest Message: JUnit Failure: test(MethodHandlesGeneralTest): Expected to get exit value of [0] Here's the crashing thread's stack trace: --------------- T H R E A D --------------- Current thread (0x00007f969e7f0fd0): GCTaskThread "GC Thread#5" [stack: 0x0000700004299000,0x0000700004399000] [id=37123] Stack: [0x0000700004299000,0x0000700004399000], sp=0x0000700004398af0, free space=1022k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x41a657] oopDesc::size_given_klass(Klass*)+0x17 V [libjvm.dylib+0x65a6fa] HeapRegion::block_size(HeapWordImpl* const*) const+0x11a V [libjvm.dylib+0x7946a6] HeapRegion::verify(VerifyOption, bool*) const+0x1b6 V [libjvm.dylib+0x6cd568] VerifyRegionClosure::do_heap_region(HeapRegion*)+0x388 V [libjvm.dylib+0x7a314f] HeapRegionManager::par_iterate(HeapRegionClosure*, HeapRegionClaimer*, unsigned int) const+0x13f V [libjvm.dylib+0x6cd1b6] G1ParVerifyTask::work(unsigned int)+0x86 V [libjvm.dylib+0x1106ce0] GangWorker::run_task(WorkData)+0x60 V [libjvm.dylib+0x1106d9c] GangWorker::loop()+0x2c V [libjvm.dylib+0xff2977] Thread::call_run()+0x1b7 V [libjvm.dylib+0xdb8ddf] thread_native_entry(Thread*)+0x15f C [libsystem_pthread.dylib+0x3661] _pthread_body+0x154 C [libsystem_pthread.dylib+0x350d] _pthread_body+0x0 C [libsystem_pthread.dylib+0x2bf9] thread_start+0xd siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000dd56dd5fc Here's the test task's description: Run test open/test/hotspot/jtreg/:hotspot_runtime with macosx-x64-debug with -XX:-UseCompressedOops #tier8-rt-main-no-coops
13-07-2020
> Time: Sun Jun 28 23:18:03 2020 /GM elapsed time: 2029.718119 seconds (0d 0h 33m 49s) > Time: Mon Jun 22 07:28:16 2020 /GM elapsed time: 45013.253113 seconds (0d 12h 30m 13s) Note these run for a long time before failing. The latest incidents on windows.
30-06-2020
This ad-hoc job looked like a train wreck, and now it's deleted. You can get a crash in oopDesc::size_given_klass if there's a bad oop, which could have been a bug in the ad-hoc job. Searches with size_given_klass and this test name don't have any results. I'm closing as CNR.
18-05-2020
ILW = HLM = P3
21-04-2020