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

Ioi Lam ioi.lam at oracle.com
Fri Aug 9 20:11:36 UTC 2019

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.

- 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

More information about the hotspot-runtime-dev mailing list