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

[Chris Plummer]

Thanks!

On 5/18/18 1:34 PM, Daniel D. Daugherty wrote:
> > 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>