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

[Daniel D. Daugherty]

 > http://cr.openjdk.java.net/~cjplummer/8185803/webrev.02/

test/jdk/ProblemList.txt
     No comments.

test/jdk/com/sun/jdi/JdbExprTest.sh
     No comments.

Thumbs up.

Dan



On 5/18/18 4:03 PM, Chris Plummer wrote:
> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>
>