RFR(M) 8243500: SA: Incorrect BCI and Line Number with jstack if the top frame is in the interpreter (BSD and Windows)
Alex Menkov
alexey.menkov at oracle.com
Tue Apr 28 01:52:42 UTC 2020
Hi Chris,
The fix looks good.
--alex
On 04/27/2020 12:17, Chris Plummer wrote:
> Ping! Please help review if you can.
>
> thanks,
>
> Chris
>
> On 4/24/20 12:44 AM, Chris Plummer wrote:
>> Hello,
>>
>> Please review the following:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8243500
>> http://cr.openjdk.java.net/~cjplummer/8243500/webrev.00/index.html
>>
>> A couple years ago JDK-8214226 fixed an issue on Linux-x64 with SA
>> stack dumps not properly displaying the correct line number for the
>> topmost frame if it was interpreted. The issue was that SA was always
>> relying on frame->bcp when in fact the BCP is kept in R13, and only
>> flushed to frame->bcp when needed as a scratch register. So this means
>> that SA was in most cases grabbing a stale value from frame->bcp.
>>
>> The fix for JDK-8214226 was mostly made in X86Frame.java to support
>> using the BCP register for the topmost frame instead using frame->bcp.
>> This fix actually had a bug in it that was causing the "illegal bci"
>> failures we've been seeing. There is already a separate webrev and RFR
>> out for that:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8231634
>> http://cr.openjdk.java.net/~cjplummer/8231634/webrev.00/index.html
>>
>> What this RFR addresses is the fact that part of the fix for
>> JDK-8214226 was in LinuxAMD64JavaThreadPDAccess.java, but the same
>> changes were never made to WindowsAMD64JavaThreadPDAccess.java or
>> BsdAMD64JavaThreadPDAccess.java. This fix addresses those two ports.
>> Here's the CR and changeset for reference:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8214226
>> http://hg.openjdk.java.net/jdk/jdk/rev/9a73a4e4011f
>>
>> The changes for the fix are pretty trivial. The more complicated part
>> is the test I added that will reproduce the issue 100% of the time on
>> platforms where SA does not properly check the BCP register. For this
>> reason I've used @requires to limit running this test on just those
>> platforms I know have the support in place. The test has pretty good
>> comments on how it works, so I won't go into details here.
>>
>> thanks,
>>
>> Chris
>
More information about the serviceability-dev
mailing list