JDK-8216427 : ciMethodData::load_extra_data() does not always unpack the last entry
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10,11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-01-09
  • Updated: 2019-10-04
  • Resolved: 2019-01-15
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 11 JDK 12 JDK 13
11.0.5Fixed 12 b28Fixed 13Fixed
Related Reports
Relates :  
Description
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.
Comments
Fix Request (11u) This backports fixes the bad corner case in compiler/runtime interaction. Patch applies cleanly to 11u, passes tier1 and tier2 tests.
25-06-2019

ILW = Corrupted method data (may lead to crashes or undefined behavior), very intermittent; seen crashes with long runs of stress tests, no workaround = HLM = P3
11-01-2019