Looks good.
Thanks,
Serguei
n 5/18/18 00:51, 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
