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.
Adding core-libs.
Thanks,
Coleen
Max
On 9/6/2016 8:24 PM, dean.l...@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[1] 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.
dl
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
