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.bal...@oracle.com] 
Sent: Wednesday, February 14, 2018 10:49 PM
To: stewartd.qdt <stewartd....@qualcommdatacenter.com>; David Holmes 
<david.hol...@oracle.com>; serviceability-dev 
<serviceability-dev@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....@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-boun...@openjdk.java.net] 
On Behalf Of David Holmes
Sent: Wednesday, February 14, 2018 12:40 AM
To: Sharath Ballal <sharath.bal...@oracle.com>; serviceability-dev 
<serviceability-dev@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
>>>

Reply via email to