RFR: JDK-8196930 - [Testbug] serviceability/sa/ClhsdbFindPC.java fails to find expected output

[stewartd.qdt]

Thanks Sharath. I did realize this patch was solving another issue, but just wanted to make you aware that the null Method issue pops up in this test as well. 

Please let me know if there is something I can do to help you solve this issue. I don't know if you are able to reproduce the issue or not, so if you need any logs or other info, I'm happy to get it for you.

Daniel

-----Original Message-----
From: Sharath Ballal [mailto:sharath.ballal at oracle.com] 
Sent: Wednesday, February 14, 2018 10:49 PM
To: stewartd.qdt <stewartd.qdt at qualcommdatacenter.com>; David Holmes <david.holmes at oracle.com>; serviceability-dev <serviceability-dev at openjdk.java.net>
Subject: RE: RFR: JDK-8196930 - [Testbug] serviceability/sa/ClhsdbFindPC.java fails to find expected output

Daniel,
This is a different problem than getting the null method.  Here we are expecting "invoke return entry points" in the output of findpc command but getting ""method entry point".
The null method problem seems to be specific to AArch64 system and I am looking at it separately.

Thanks,
Sharath


-----Original Message-----
From: stewartd.qdt [mailto:stewartd.qdt at qualcommdatacenter.com]
Sent: Thursday, February 15, 2018 12:05 AM
To: David Holmes; Sharath Ballal; serviceability-dev
Subject: RE: RFR: JDK-8196930 - [Testbug] serviceability/sa/ClhsdbFindPC.java fails to find expected output

This test actually fails for me for the same reason that ClhsdbJstack.java fails, there is a frame in the stack of the main method that is returning null for the method. See the OpenJDK bug at https://bugs.openjdk.java.net/browse/JDK-8196969 for details of that issue. 

In this case I get the same problem, that a Method is null in the stack, which then causes a failure at 73 of ClhsdbFindPC.java. 

Daniel

-----Original Message-----
From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
Sent: Wednesday, February 14, 2018 12:40 AM
To: Sharath Ballal <sharath.ballal at oracle.com>; serviceability-dev <serviceability-dev at openjdk.java.net>
Subject: Re: RFR: JDK-8196930 - [Testbug] serviceability/sa/ClhsdbFindPC.java fails to find expected output

On 14/02/2018 3:29 PM, Sharath Ballal wrote:
> -----Original Message-----
> From: David Holmes
> Sent: Wednesday, February 14, 2018 10:53 AM
> To: Sharath Ballal; serviceability-dev
> Subject: Re: RFR: JDK-8196930 - [Testbug] 
> serviceability/sa/ClhsdbFindPC.java fails to find expected output
> 
> On 14/02/2018 3:11 PM, Sharath Ballal wrote:
>> David,
>> When I wrote these tests, I looked for the output generated by these commands.  The output I saw was same (across windows, mac, linux) and hence grepped for certain strings from it.
>> Now we are seeing some issues where depending on the hardware we are at different execution point and hence some of the strings are changing.  So now I am removing such strings from the test.
>> The main intention of these tests are to check the basic sanity that the SA command is working.
> 
>> Ok. But based on "In interpreter codelet" I would expect this would fail if run in -Xcomp mode ??
> This test works in both Xcomp and Xint mode.  "In interpreter codelet" is being checked for Xint, for Xcomp we are checking "In code in NMethod for jdk/test/lib/apps/LingeredApp.main"

Yep sorry - missed that bit.

David

> 
> Thanks,
> David
> 
>> Thanks,
>> Sharath
>>
>>
>> -----Original Message-----
>> From: David Holmes
>> Sent: Wednesday, February 14, 2018 7:38 AM
>> To: Sharath Ballal; serviceability-dev
>> Subject: Re: RFR: JDK-8196930 - [Testbug] 
>> serviceability/sa/ClhsdbFindPC.java fails to find expected output
>>
>> Hi Sharath,
>>
>> On 12/02/2018 7:12 PM, Sharath Ballal wrote:
>>> Hello,
>>>
>>> Requesting reviews for the issue:
>>>
>>> ID: https://bugs.openjdk.java.net/browse/JDK-8196930
>>>
>>> Webrev: http://cr.openjdk.java.net/~sballal/8196930/webrev.00/
>>
>> I've no doubt this makes the test pass, but I always have to wonder with these tests: why was it looking for the thing now removed? what changed (or in what way was the expected output invalid) to make the test fail?
>>
>> Thanks,
>> David
>>
>>> Tests run: The SA tests pass with Mach5.
>>>
>>> Thanks,
>>>
>>> Sharath
>>>