RFR(S): 8185803: JdbExprTest.sh fails in JDK10-hs nightly due to "Name unknown: java.lang.Long.MAX_VALUE "

[David Holmes]

Looks fine.

There are simpler expression to ensure initialization of Long but it 
doesn't really matter.

Thanks,
David

On 18/05/2018 5:51 PM, Chris Plummer wrote:
> Hi,
> 
> I'm reviving this RFR since it looks like JDK-8179318 might not be fixed 
> for a while.
> 
> https://bugs.openjdk.java.net/browse/JDK-8185803
> http://cr.openjdk.java.net/~cjplummer/8185803/webrev.02/
> 
> Since it still fails on solaris-sparc due to 8203393, I updated 
> ProblemList.txt to reflect this.
> 
> thanks,
> 
> Chris
> 
> On 5/11/18 1:14 PM, Chris Plummer wrote:
>> Actually I did notice that and had a new webrev ready to go out and en 
>> email drafted, but then noticed the solaris-sparc timeout when I 
>> tested again.
>>
>> Chris
>>
>> On 5/10/18 9:50 PM, David Holmes wrote:
>>> I was going to say that you also need to remove:
>>>
>>>   29 #  @requires os.family != "windows"
>>>   30 #  @key intermittent
>>>
>>> :)
>>>
>>> But something seems fishy about this bug to me anyway - comments 
>>> added to bug report.
>>>
>>> Cheers,
>>> David
>>>
>>> On 11/05/2018 12:59 PM, Chris Plummer wrote:
>>>> Hello,
>>>>
>>>> I'm withdrawing this RFR. I noticed with repeated runs it was 
>>>> sometimes failing on Solaris. It looks like for the most part the 
>>>> test ran ok, but then at the end of the log you see:
>>>>
>>>> --Finish execution with sending "quit" command to JDB
>>>> --Sending cmd: quit
>>>> --Quit cmd was sent
>>>> --waitForFinish: Waiting for mydojdbCmds() to finish
>>>>
>>>> And it never returns from this. It looks to be the same issue as 
>>>> JDK-8171483 <https://bugs.openjdk.java.net/browse/JDK-8171483>, but 
>>>> with a different test. Since the shell script stability issues will 
>>>> be resolved when the scripts are converted to pure java tests by 
>>>> JDK-8179318 <https://bugs.openjdk.java.net/browse/JDK-8179318>, I 
>>>> think it's best to just let this bug be fixed at the same time as 
>>>> JDK-8179318 <https://bugs.openjdk.java.net/browse/JDK-8179318>. I 
>>>> was hoping to get the test stable and off the problemlist with this 
>>>> fix, but since that's not 100% attainable, it's not really worth 
>>>> pushing the fix at this time.
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>> On 5/10/18 5:01 PM, Chris Plummer wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following simple fix for 8185803:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8185803
>>>>> http://cr.openjdk.java.net/~cjplummer/8185803/webrev.00/
>>>>>
>>>>> Although this bug has been around for nearly a year, it used to 
>>>>> only fail on Windows. After the push for JDK-8198426 last month, it 
>>>>> started to fail on every run. The test runs jdb, stops at a 
>>>>> breakpoint in the debugee, and the issues the following command:
>>>>>
>>>>>    print java.lang.Long.MAX_VALUE
>>>>>
>>>>> And the response back is:
>>>>>
>>>>> com.sun.tools.example.debug.expr.ParseException: Name unknown: 
>>>>> java.lang.Long.MAX_VALUE
>>>>>    java.lang.Long.MAX_VALUE = null
>>>>>
>>>>> The issue is that Long has not been initialized (it has been 
>>>>> loaded), so the java.lang.Long.MAX_VALUE symbol is not valid. This 
>>>>> became the case on every run after JDK-8198426 because it removed a 
>>>>> bunch of java code that executed at startup, and this code must 
>>>>> have been causing Long to get initialized. I'm not sure why it used 
>>>>> to only fail on Windows before JDK-8198426, but it passes now on 
>>>>> all platforms with my fix, which is to add a reference to 
>>>>> java.lang.Long in the debugee so the Long will always be initialized.
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>>
>>
>>
> 
>