-
Bug
-
Resolution: Fixed
-
P3
-
11.0.11
-
b07
-
x86
-
linux
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8270919 | 17.0.1 | William Kemper | P3 | Resolved | Fixed | b03 |
JDK-8270557 | 17 | William Kemper | P3 | Resolved | Fixed | b32 |
JDK-8270285 | 15.0.5 | William Kemper | P3 | Resolved | Fixed | b01 |
JDK-8270528 | 13.0.9 | Anton Kozlov | P3 | Resolved | Fixed | b01 |
JDK-8270383 | 11.0.13-oracle | Harold Seigel | P3 | Resolved | Fixed | b02 |
JDK-8270242 | 11.0.13 | William Kemper | P3 | Resolved | Fixed | b01 |
```
V [libjvm.so+0x6cba4c] DefNewGeneration::copy_to_survivor_space(oopDesc*)+0xac
V [libjvm.so+0x58869c] FastScanClosure::do_oop(oopDesc**)+0x8c
V [libjvm.so+0x60bb6a] ClassLoaderData::oops_do(OopClosure*, bool, bool)+0x7a
V [libjvm.so+0x6c9c8a] CLDScanClosure::do_cld(ClassLoaderData*)+0x3a
V [libjvm.so+0x60e3c9] ClassLoaderDataGraph::roots_cld_do(CLDClosure*, CLDClosure*)+0x39
V [libjvm.so+0x822beb] GenCollectedHeap::young_process_roots(StrongRootsScope*, OopsInGenClosure*, OopsInGenClosure*, CLDClosure*, OopStorage::ParState<false, false>*)+0x26b
V [libjvm.so+0x6cc8ed] DefNewGeneration::collect(bool, bool, unsigned long, bool)+0x4bd
V [libjvm.so+0x823c8d] GenCollectedHeap::collect_generation(Generation*, bool, unsigned long, bool, bool, bool, bool)+0x26d
V [libjvm.so+0x824548] GenCollectedHeap::do_collection(bool, bool, unsigned long, bool, GenCollectedHeap::GenerationType)+0x2e8
V [libjvm.so+0x8252b8] GenCollectedHeap::satisfy_failed_allocation(unsigned long, bool)+0x1e8
V [libjvm.so+0xf37f0f] VM_GenCollectForAllocation::doit()+0x8f
V [libjvm.so+0xf39547] VM_Operation::evaluate()+0xe7
V [libjvm.so+0xf3fa06] VMThread::evaluate_operation(VM_Operation*) [clone .constprop.67]+0xb6
V [libjvm.so+0xf3ff38] VMThread::loop()+0x428
V [libjvm.so+0xf403d3] VMThread::run()+0x73
```
It's crashing on `oop->size()`. The oop here is passed in RDI, RAX holds the `klass` pointer (which is null here):
```
RAX=0x0 is NULL
...
RDI=0x0000000800099120 is pointing into metadata
```
The metadata here is mapped to the shared archive:
```
800000000-800003000 rwxp 00001000 fe:00 543305 /var/lang/lib/server/runtime.jsa
800003000-80064b000 rw-p 00004000 fe:00 543305 /var/lang/lib/server/runtime.jsa
80064b000-80107f000 r--p 0064c000 fe:00 543305 /var/lang/lib/server/runtime.jsa
80107f000-801080000 rw-p 01080000 fe:00 543305 /var/lang/lib/server/runtime.jsa
801080000-801a90000 r--p 01081000 fe:00 543305 /var/lang/lib/server/runtime.jsa
```
Crash log file is attached. The environment here makes it difficult to collect core files or make changes to the command line parameters. I suspect it's an issue with CDS.
- backported by
-
JDK-8270242 Corrupt oop in ClassLoaderData
- Resolved
-
JDK-8270285 Corrupt oop in ClassLoaderData
- Resolved
-
JDK-8270383 Corrupt oop in ClassLoaderData
- Resolved
-
JDK-8270528 Corrupt oop in ClassLoaderData
- Resolved
-
JDK-8270557 Corrupt oop in ClassLoaderData
- Resolved
-
JDK-8270919 Corrupt oop in ClassLoaderData
- Resolved
- duplicates
-
JDK-8270024 ClassLoaderData::init_handle_locked adding ClassLoaderData oop misses record_modified_oops
- Closed
- links to
-
Commit openjdk/jdk11u-dev/3ce8c728
-
Commit openjdk/jdk13u-dev/031496dd
-
Commit openjdk/jdk15u-dev/34b00be9
-
Commit openjdk/jdk17/e104dede
-
Commit openjdk/jdk/3586a233
-
Review openjdk/jdk11u-dev/114
-
Review openjdk/jdk13u-dev/234
-
Review openjdk/jdk15u-dev/76
-
Review openjdk/jdk17/240
-
Review openjdk/jdk/4701