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

[David Holmes]

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