Thanks David.
Thanks,
Sharath
-Original Message-
From: David Holmes
Sent: Thursday, September 27, 2018 7:43 PM
To: Sharath Ballal; Jini Susan George; serviceability-dev
Subject: Re: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times
out parsing a 4GB hprof file
LGTM.
Tha
Revised webrev:
Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev.01/
The final fix includes
- updated the timeout for the test (should handle sparc debug slowness)
- wait for explicit prompts from cont command (avoids confusion
from "int[2]")
- fixed a typo in an exclude
At this point my first recommendation is to
simply remove the test from the ProblemList,
since it has not been reproduced after 1000s of
testruns with debug and release builds.
What is not clear to me at the moment is -
was it intentional that hs201t001 intentionally placed
the classloader operat
Hi Sharath,
what do you think about bringing this fix to jdk11u?
We run the tests there regularly and see this problem, too.
Best regards,
Goetz.
> -Original Message-
> From: serviceability-dev On
> Behalf Of Sharath Ballal
> Sent: Montag, 24. September 2018 05:49
> To: serviceabilit
Hi Jc,
Overall looks good.
Could you please update
ForceEarlyReturn/ForceEarlyReturn001/ForceEarlyReturn001.cpp manually -
converted calls contain a lot of unnecessary spaces.
--alex
On 09/27/2018 22:15, JC Beyler wrote:
Hi all,
I continued the NSK_CPP_STUB removal with this webrev:
Webre
+1 for webrev.05
--alex
On 09/28/2018 04:25, serguei.spit...@oracle.com wrote:
Hi Jc,
I agree it can be refactored later so I'm Okay with the current webrev.
Thanks,
Serguei
On 9/27/18 8:57 PM, JC Beyler wrote:
Hi Serguei,
Exactly, I'm taking the lazy approach and just doing the ones I nee
To let you know, me and Tom R. did review these changes and agreed that it is the least intrusive
changes for Hotspot shared code.
Thanks,
Vladimir
On 9/25/18 8:11 AM, Daniel D. Daugherty wrote:
Adding serviceability-dev@... since this is JVM/TI...
Dan
On 9/25/18 10:48 AM, Doug Simon wrote:
Hi Gary,
receiveReply(startPos, false, 0)
calls
waitForPrompt(startPos, compoundPromptOnly, count);
and waitForPrompt has:
if (count <= 0) {
throw new TestBug("Wrong number of prompts count in
Jdb.waitForPrompt(): " + count);
}
So We will get "Wrong number of promp
Yep. My suggestion was to use this version of receiveReply(), but also
have receiveReply() not call waitForPrompt() if count was 0. I think it
would be good to test with this change in place, but with a smaller
timeout so you can reproduce the timeout error and test this
receiveReply() call. Ot
I think I'd pref to just submit the exclude001 fix at this time without the
Jdb.java changes.
We can revisit this wait for message diagnostic clean up along with the
kill002
fix.
On 9/28/18, 2:15 PM, Chris Plummer wrote:
Yep. My suggestion was to use this version of receiveReply(), but also
h
I'm fine with keeping the Jdb changes out of this exclude001 fix, but I
don't see what it has to do with kill002. IIRC the bug with that test is
that it is only waiting for the first of two prompts that come in, so
sometimes it returns the reply too early.
Chris
On 9/28/18 11:20 AM, Gary Adam
The kill002 logs I saw returned after the matching message e.g. "xxx killed"
When the pending output was dumped it included next prompt,
but the next prompt was not returned. This could have been a
similar situation to the exclude timeout, which then ended up
doing a wait for prompt as part of gat
Patch attached.
On 9/28/18, 2:23 PM, Chris Plummer wrote:
I'm fine with keeping the Jdb changes out of this exclude001 fix, but
I don't see what it has to do with kill002. IIRC the bug with that
test is that it is only waiting for the first of two prompts that come
in, so sometimes it returns
+1 for exclude001 fix without the Jdb.java changes
--alex
On 09/28/2018 11:23, Chris Plummer wrote:
I'm fine with keeping the Jdb changes out of this exclude001 fix, but I
don't see what it has to do with kill002. IIRC the bug with that test is
that it is only waiting for the first of two prom
That's not quite the reason why kill002 failed. When doing a kill
command, there are two prompts printed. One is printed immediately after
issuing the async kill command, and the other after the async kill
command completes. We first wait for the "killed" message, and then wait
for the prompt.
Hi Gary,
If you haven't been able to reproduce the failure and just want to take
it off the problemlist, I'm ok with that. I'd rather not see any test
changes that could potentially hide the crash. If it eventually fails
for some other reason and it can be shown that it is testbug due to
impr
Hi all,
please take a look ar a fix for
https://bugs.openjdk.java.net/browse/JDK-8209332
webrev:
http://cr.openjdk.java.net/~amenkov/sh2java/CatchPattern/webrev.01/
The fix converts the test from shell to java and fixes ""ignore" command
to match corresponding "catch" commands
--alex
Hi Alex,
The fix looks good for me.
Thanks.
-Daniil
On 9/28/18, 2:28 PM, "serviceability-dev on behalf of Alex Menkov"
wrote:
Hi all,
please take a look ar a fix for
https://bugs.openjdk.java.net/browse/JDK-8209332
webrev:
http://cr.openjdk.java.net/~amenkov/sh2java
+1
Chris
On 9/28/18 3:25 PM, Daniil Titov wrote:
Hi Alex,
The fix looks good for me.
Thanks.
-Daniil
On 9/28/18, 2:28 PM, "serviceability-dev on behalf of Alex Menkov"
wrote:
Hi all,
please take a look ar a fix for
https://bugs.openjdk.java.net/browse/JDK-8209332
Hi Alex,
Thanks for the review and nice catch. I updated my scripts and now fix that
corner case. Here is the incremental webrev that fixes a few more white
space issues:
Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.00_01
Bug: https://bugs.openjdk.java.net/browse/JDK-8211261
The fu
Hi JC,
In addition to Alex's ForceEarlyReturn001.cpp comment:
There are many places where I see a space between two parens at the end
of the line. For example, in attach020Agent00.cpp:
168 if (!NSK_JVMTI_VERIFY(jvmti->AddCapabilities(&caps)) ) {
Every place NSK_JNI_VERIFY is used there
21 matches
Mail list logo
