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

[Chris Plummer]

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
>>>
>>
>>