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 |
Very occasionally (but frequently enough to cause problems), we see a crash in the Serial collector when it's visiting oops in the `ClassLoaderData`. In these cases, the application is invoked with `-Xshare:on`. The stack trace looks like:
```
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.
```
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-8270242Corrupt oop in ClassLoaderData
- Resolved
JDK-8270285Corrupt oop in ClassLoaderData
- Resolved
JDK-8270383Corrupt oop in ClassLoaderData
- Resolved
JDK-8270528Corrupt oop in ClassLoaderData
- Resolved
JDK-8270557Corrupt oop in ClassLoaderData
- Resolved
JDK-8270919Corrupt oop in ClassLoaderData
- Resolved
- duplicates
JDK-8270024ClassLoaderData::init_handle_locked adding ClassLoaderData oop misses record_modified_oops
- Closed
- links to
Commitopenjdk/jdk11u-dev/3ce8c728
Commitopenjdk/jdk13u-dev/031496dd
Commitopenjdk/jdk15u-dev/34b00be9
Commitopenjdk/jdk17/e104dede
Commitopenjdk/jdk/3586a233
Reviewopenjdk/jdk11u-dev/114
Reviewopenjdk/jdk13u-dev/234
Reviewopenjdk/jdk15u-dev/76
Reviewopenjdk/jdk17/240
Reviewopenjdk/jdk/4701
(1 backported by, 1 duplicates, 10 links to)