RFR: 8163014: Mysterious/wrong value for "long" frame local variable on 64-bit
coleen.phillimore at oracle.com
Wed Sep 7 13:35:00 UTC 2016
On 9/7/16 9:09 AM, Max Ockner wrote:
> Does the stackwalk API have access to the type of variable at each
> slot? Where is this information stored? My operating assumption was
> that it did not have this information, and therefore needed to read
> the garbage slot.
This is true. The StackWalk API does not have type information for
these longs, so this prevents garbage values from being read.
> On 9/6/2016 8:24 PM, dean.long at oracle.com wrote:
>> Instead of fixing this at write time, how about instead fixing it at
>> read time? That was my understanding of John's comment:
>> A virtualized API which
>> produces a view on such an L needs to return some
>> default value (if pressed), and to indicate that the slot
>> has no payload.
>> SoLiveStackFrame.getLocals() would never read the physical garbage
>> slot, but instead would act as if it
>> read 0 instead. And by LiveStackFrame.getLocals() I really mean
>> whatever code fills in its "locals" field,
>> which I guess is the JVM.
>> On 9/6/16 2:33 PM, Max Ockner wrote:
>>> Hello, Please review this multi-platform fix for the stack walk API.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163014 Webrev:
>>> http://cr.openjdk.java.net/~mockner/8163014.01/ In 64 bits, long
>>> values can fit into a single slot, but two slots are still used. The
>>> high slot contains garbage. This normally wouldn't matter since it
>>> is never read from but the stack walk API expects to display useful
>>> information. This is an issue when displaying longs from local
>>> variables, so this means we can kill any garbage off by zeroing it
>>> when it is pushed to the stack in the previous frame. This solution
>>> zeroes the high byte of a long value when it is being pushed to the
>>> stack (in push_l). This applies to x86, aarch64, and sparc. This
>>> change does not apply to ppc, though the bug almost certainly does
>>> affect it. I have left ppc untouched since I don't have access to
>>> the hardware required to reproduce the bug and test the fix. I have
>>> adapted the reproducer from the bug into a test. It is curently
>>> sitting in runtime/locallong, but I believe there must be a better
>>> place for it. Thanks, Max
More information about the core-libs-dev