RFR(XS): JDK-8229375 Memory corruption in the implementation of the stack walk API

[Ioi Lam]

On 8/9/19 12:57 PM, dean.long at oracle.com wrote:
> Maybe it's overkill, but another option would be to auto-generate or 
> auto-check these C++ accessors using a separate tool that reads the 
> .class files.
>
I think we had to do the manual field lookup because the hotspot-express 
model could support different versions of core libraries, so some fields 
might be missing in certain classes.

Now that hotspot is intrinsically hard wired to a specific JDK build, I 
think we should auto-generate these field accessors.

Thanks
- Ioi

> dl
>
> On 8/9/19 12:51 PM, dean.long at oracle.com wrote:
>> It would be nice if we could detect problems like this 
>> automatically.  Since this is an oop, we could figure out the field 
>> type at the given offset (slow).  Or keep around the type information 
>> that was given to STACKFRAMEINFO_FIELDS_DO and compute a {offset, 
>> size} tuple instead.
>>
>> dl
>>
>> On 8/9/19 9:54 AM, Frederic Parain wrote:
>>> Greetings,
>>>
>>> please review this one line change to fix a memory corruption
>>> issue in the stack walk API implementation.
>>>
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8229375
>>> Webrev: 
>>> http://cr.openjdk.java.net/~fparain/8229375/webrev.00/index.html
>>>
>>> Thank you,
>>>
>>> Fred
>>>
>>
>