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

[Chris Plummer]

Thanks David!

Can I get one more reviewer? I'd like to get this pushed so I can move 
onto to another simple fix that needs to wait for this one.

thanks,

Chris

On 5/18/18 1:18 AM, David Holmes wrote:
> 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
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>