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
