-
Bug
-
Resolution: Fixed
-
P3
-
9, 10, 11, 12, 13
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8217174 | 13 | Erik Österlund | P3 | Resolved | Fixed | b04 |
| JDK-8217539 | 12.0.1 | Erik Österlund | P3 | Resolved | Fixed | b04 |
| JDK-8227520 | 11.0.6-oracle | Erik Österlund | P3 | Resolved | Fixed | b01 |
| JDK-8227143 | 11.0.5 | Erik Österlund | P3 | Resolved | Fixed | b01 |
When unpacking the extra data section of the MDOs, the source and destination might not have the same number of entries, because there can be safepoints between cloning the extra data section of the MDO and unpacking the source entries to the destination entries.
Therefore the unpacking loop loops through all the source entries and copies them to the destination. Except the last DataLayout::arg_info_data_tag entry, that never gets copied form the source to the destination. Therefore, if a safepoint occurred between cloning the extra data section and unpacking its entries in ciMethodData::load_extra_data(), the last entry could contain random bogus memory.
It seems like the reason the last entry is not copied is because the copying requires a length which is calculated by taking the difference between the current entry and the next entry in the loop. But as there is no next entry when you are at the last entry, the copying is simply not performed, instead of calculating what the length of that entry would be.
Therefore the unpacking loop loops through all the source entries and copies them to the destination. Except the last DataLayout::arg_info_data_tag entry, that never gets copied form the source to the destination. Therefore, if a safepoint occurred between cloning the extra data section and unpacking its entries in ciMethodData::load_extra_data(), the last entry could contain random bogus memory.
It seems like the reason the last entry is not copied is because the copying requires a length which is calculated by taking the difference between the current entry and the next entry in the loop. But as there is no next entry when you are at the last entry, the copying is simply not performed, instead of calculating what the length of that entry would be.
- backported by
-
JDK-8217174 ciMethodData::load_extra_data() does not always unpack the last entry
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
-
- Resolved
-