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

[Chris Plummer]

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
>