Here's a simple fix to include additional information when the
instrument library is
missing from the jre and the command line requests -javaagent.
Issue: https://bugs.openjdk.java.net/browse/JDK-8180709
Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.00/
Here's a simple fix to correct the error message when the java_pid socket
is not found. The code previously reported the attach_pid file name
rather than the socket file name that was not found.
Issue: https://bugs.openjdk.java.net/browse/JDK-8188856
Webrev:
On 12/18/17, 4:38 PM, Chris Plummer wrote:
On 12/18/17 1:22 PM, gary.ad...@oracle.com wrote:
On 12/18/17 2:26 PM, Chris Plummer wrote:
Hi Gary,
On 12/18/17 6:47 AM, Gary Adams wrote:
Here's a simple fix to correct the error message when the java_pid
socket
is not found. The code previously
A refreshed webrev is vailable
Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.01/
On 12/19/17, 5:10 AM, Alan Bateman wrote:
On 18/12/2017 21:14, gary.ad...@oracle.com wrote:
I can just the error message.
What would you like it to say?
"Module java.instrument may be missing"
A refreshed webrev is available
Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.01/
On 12/18/17, 4:38 PM, Chris Plummer wrote:
On 12/18/17 1:22 PM, gary.ad...@oracle.com wrote:
On 12/18/17 2:26 PM, Chris Plummer wrote:
Hi Gary,
On 12/18/17 6:47 AM, Gary Adams wrote:
Here's
Looking into some minor bugs in the attach area for the next release.
https://bugs.openjdk.java.net/browse/JDK-8188856
Seems like a minor change to fix this error message that mentions the
java_pid socket file,
but then outputs the attach_pid file when the socket file is not created .
What
On 12/15/17, 9:14 AM, Daniel D. Daugherty wrote:
On 12/15/17 9:05 AM, Gary Adams wrote:
Looking into some minor bugs in the attach area for the next release.
https://bugs.openjdk.java.net/browse/JDK-8188856
Seems like a minor change to fix this error message that mentions the
java_pid
Is the patch file in the webrev sufficient?
http://bussund0416.us.oracle.com/export/users/gradams/work/webrevs/8180709/webrev.01/jdk-hs.patch
For testing I had been running the closed tonga all.testlist and the
open jdk-tier1 tests.
But to demonstrate the error message, I would locally
It's theoretically possible that the corrupted output
could be produced with a single step command
because of the separate event handler and command
processing threads, although the failures that have
been recorded were all observed later in a test scenario.
So let's look at a third possible way
There are some rare race conditions that impact some jvmti tests that
suspend and resume threads. These tests were recently moved into
the open repos.
Webrev: http://cr.openjdk.java.net/~gadams/6545967/webrev.00/
The fix in hs203t003 replaces a blind 10 second sleep, with a specific
check to
A patch was done previously to prevent an error when -XX:-UsePerfData
is used, but this bug was filed to make the setting more visible in the
jdk.internal.perf package.
Webrev: http://cr.openjdk.java.net/~gadams/8069149/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8069149
I
Comments inline ...
On 6/1/18, 7:45 AM, Gary Adams wrote:
PS.
PerfCounter.java
lb field should be left as final. You can work around
definite-assignment problems by using a local variable and only
assigning to the field after the catch block:
private PerfCounter(String name, int type
sed fix is in the open code.
Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev/
Forwarded Message
Subject: RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR:
Cannot find boolVar with expected value: false
Date: Fri, 25 May 2018 11:35:10 -0400
From:
akpoint. I don't think your solution does the same.
My goal is to delay the sending of the next command,
because the debuggee is not actually ready for the command.
Chris
On 6/6/18 10:07 AM, Gary Adams wrote:
It may be sufficient when the command prompt is delivered
to introduce a brief pa
d*
Step completed: *"thread=main", nsk.jdb.eval.eval001.eval001a.runIt(),
line=36 bci=53*
36}
**
Sending command: eval nsk.jdb.eval.eval001.eval001a.myStaticField
main[1]
* delay after command*
...
I'll try
e to this would need to go through a rigorous
process to determine impact. So I'd say that's future work beyond the
scope of the current RFE/bug.
Thanks,
David
On 1/06/2018 11:06 PM, Gary Adams wrote:
Comments inline ...
On 6/1/18, 7:45 AM, Gary Adams wrote:
PS.
PerfCounter.java
lb field
.
The failure we see in JDK-8205508 is hitting the internal timeout
of the vmTestbase wrapper, not the external jtreg harness.
On 6/26/18, 8:58 AM, David Holmes wrote:
On 26/06/2018 9:15 PM, Gary Adams wrote:
For the vmTestbase tests recently moved to the open repos,
see test/hotspot/jtreg/vmTestbase
The exclude001 test times out on solaris sparc debug builds.
Basically, this test is all about tracing method calls and introduces
exclude filters to reduce the callbacks to a select set of packages.
The time spent tracing/filtering method callbacks is purely a function
of the number of methods
for
this test. There could be an underlying issue that needs to be addressed.
Chris
On 6/25/18 11:00 AM, serguei.spit...@oracle.com wrote:
Hi Gary,
It looks Okay.
But I'm curious when this started failing and what triggered it to fail?
Thanks,
Serguei
On 6/25/18 10:20, Gary Adams wrote
if ((mt.threadState < 1000) &&
106 agentStatus()) {
107 passed = true;
108 }
Lines 105 and 106 should be combined.
thanks
Chris
On 6/20/18 5:31 AM, Gary Adams wrote:
We do need to consider an early return for the case where
the redefine class or suspend thread ope
in the test, before any timeout factor is applied.
Which would you prefer at this point in time :
- increase the timeout so it can run on the slower platforms
- problem list the test so it is bypassed completely
On 6/26/18, 1:45 AM, David Holmes wrote:
Hi Gary,
On 26/06/2018 4:27 AM, Gary
Getting the sources ready for the next Solaris developer studio toolchain.
Some additional warnings were found in the debug build.
Issue: https://bugs.openjdk.java.net/browse/JDK-8202319
Webrev: http://cr.openjdk.java.net/~gadams/8202319/webrev.00/
This update conditionally disables some
theoreticals here, since it is just for testing purposes
and solves the issue on the platforms we know of. So thumbs up.
Chris
On 1/11/18 8:28 AM, Gary Adams wrote:
Here's a simple fix to the split pattern when output lines are using
mixed line
separators in the same outputstream . e.g. split
Here's a simple fix to the split pattern when output lines are using
mixed line
separators in the same outputstream . e.g. split("\r\n|\n")
Issue: https://bugs.openjdk.java.net/browse/JDK-8031482
Webrev: http://cr.openjdk.java.net/~gadams/JDK-8031482
testing in progress ...
Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS
build flag and update the winsock deprecated functions.
Issue: https://bugs.openjdk.java.net/browse/JDK-8080990
Webrev: http://cr.openjdk.java.net/~gadams/8080990/
These are the initial deprecated functions updated:
On 2/1/18, 6:59 AM, Langer, Christoph wrote:
But WSASendDisconnect isn't deprecated, right? So you wanted to get rid of it?
I still don't see the reason...
vs2013 include/um/winsock2.h has WSASendDisconnect deprecated.
.../src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c(230) :
tbyname: unknown host");
you should change the description text of the error to getaddrinfo
instead of gethostbyname.
Best regards
Christoph
-Original Message-
From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf
Of Gary Adams
Sent: Donnerstag, 25. Janu
I've done a little bit more investigation to learn how detach and execute
are expected to work. Looking at the solaris implementation, detach
actually closes
the file descriptor and the check in execute is is fd == -1.
In the macosx implementation the check uses path == null.
So to correct the
.
Bypassed the mach5 errors I was seeing by moving over to testing with
jdk/jdk repos.
If this is acceptable, I'll create an hg export patch file for
my sponsor.
On 12/21/17, 3:17 PM, Gary Adams wrote:
A refreshed webrev is available
Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.
/execute logic
- a few minor differences between the various platform specific files
curly braces and exception args.
Ran into some issues with mach5 testing which will require another
test run tomorrow.
On 12/19/17, 10:00 AM, Gary Adams wrote:
A refreshed webrev is available
Webrev
Redefined())&&
102 agentStatus() ) {
103 passed = true;
104 }
105 return passed;
106 }
It seems, the two checks ( redefineAttempted() && isRedefined()) at
L101 are not needed any more.
Now, there is no way out of the while
that occurs by proceeding to the breakpoint set in MethodForCommunication
before the debugger has compared expected suspend counts.
Webrev: http://cr.openjdk.java.net/~gadams/8170089/webrev.01/index.html
On 7/17/18, 11:33 AM, Gary Adams wrote:
A race condition exists between the debugger
Should you capture the return from sleep() to make sure the accumulated
timeout of 20 seconds is achieved? Worst case scenario - every sleep is
immediately interrupted.
On 8/3/18, 2:37 PM, Gary Adams wrote:
Hello,
Please review the following fix for JDK12:
http://cr.openjdk.java.net
There's a fairly old bug concerning jvmti thread start and end events.
I believe there are 2 possible race conditions in the threadstart003
test based on some arbitrary timeout values used in the test itself.
Here are a few snippets from the test to illustrate the problem area.
In the initial
'd be included to put the wait into
a for-loop and use 1-second timeouts per iteration ie.
// wait for up to 3 seconds
for (int i = 0 ; i < 3 ; i++) {
err = (*jvmti)->RawMonitorWait(jvmti, wait_lock, (jlong)WAIT_TIME);
if (endsCount == endsExpected)
break;
}
Thanks,
David
On
I'll need a sponsor for the patch attached.
On 8/6/18, 7:16 AM, Gary Adams wrote:
On 8/3/18, 6:38 PM, Chris Plummer wrote:
Hi Gary,
Overall it looks good.
Is the EventHandler.isDisconnected() check needed?
This just follows the pattern used in other calls to setValue.
No point in attempting
Thee are several reported problems using jcmd for obtaining heap dumps.
Some users are confused by the positional argument for a filename
when a similar jfr command uses "key=value" syntax.
Some users are confused by the basic nature of the command, where the jvm
executing the heap dump is
h output"? Just seems like it has something to
do with the ordering of output, but it seems bad that the code ever
relied on a yield to make sure the output was ordered properly.
Also in the above code snippet, you need to be careful when
replacing MessageOutput.lnprint() with MessageOutput.
some minimal amount of cleanup while we are in the code.
thanks,
Chris
On 8/3/18 11:04 AM, Gary Adams wrote:
Here is an updated webrev with the alternate solution implemented for
resume 1 to 10. The debugger sets testCase variable in the debuggee
when each test case completes in the debugger
On 8/6/18, 1:56 PM, Chris Plummer wrote:
On 8/6/18 4:16 AM, Gary Adams wrote:
On 8/3/18, 6:38 PM, Chris Plummer wrote:
Hi Gary,
Overall it looks good.
Is the EventHandler.isDisconnected() check needed?
This just follows the pattern used in other calls to setValue.
I'm not seeing any other
i
On 8/6/18 05:27, Gary Adams wrote:
I'll need a sponsor for the patch attached.
On 8/6/18, 7:16 AM, Gary Adams wrote:
On 8/3/18, 6:38 PM, Chris Plummer wrote:
Hi Gary,
Overall it looks good.
Is the EventHandler.isDisconnected() check needed?
This just follows the pattern used in o
David pointed out the flaw in this test a long time ago, but
no one followed through to fix the test. When the test thread
runs to completion, there is no way to get the thread info
for the comparisons being made in checkInfo().
The test already calls checkInfo before starting the thread
and
Here's an updated webrev with the isDisconnected checks removed
in the setValue handling.
http://cr.openjdk.java.net/~gadams/8170089/webrev.02/index.html
Testing is in progress, but no failed tests have shown up so far
with the extra check removed.
On 8/22/18, 1:05 PM, Gary Adams wrote
the debuggeeClass
!= null check. Is it possible for it to ever be null? That kind of
seems along the lines of the isDisconnected() check.
Other than that the changes look fine.
thanks,
Chris
On 8/24/18 5:32 AM, Gary Adams wrote:
Here's an updated webrev with the isDisconnected checks removed
I'll need a sponsor to push the attached patch.
On 8/27/18, 10:49 PM, serguei.spit...@oracle.com wrote:
+1
Thanks,
Serguei
On 8/27/18 13:04, Chris Plummer wrote:
+1
Chris
On 8/27/18 10:46 AM, Alex Menkov wrote:
Looks good to me.
--alex
On 08/27/2018 10:30, Gary Adams wrote:
You
This message may have been lost in the vacation email backlog, so I'm
sending it again.
On 8/9/18, 2:19 PM, Gary Adams wrote:
Thee are several reported problems using jcmd for obtaining heap dumps.
Some users are confused by the positional argument for a filename
when a similar jfr command
(InterruptedException e) {}
On 8/27/18, 1:01 PM, Alex Menkov wrote:
On 08/27/2018 05:08, Gary Adams wrote:
I just tried the suggestion to add the check after thread1 join call
and it fails with :
Thread thread1: invalid thread group
If a thread completes and we join the thread, not all
checkInfo for t_a after t_a.join()
Then the test will cover 3 cases - before thread is started, while
thread is running (checkInfo from thread.run()) and after thread
termination.
--alex
On 08/24/2018 05:19, Gary Adams wrote:
David pointed out the flaw in this test a long time ago, but
no one
be updated to
243 if (endsCount == endsExpected || err != JVMTI_ERROR_NONE) {
244 break;
245 }
--alex
On 08/14/2018 10:03, Gary Adams wrote:
I did 1000 testruns with these changes. There were 3 failures due to
"executor timeout"
but those are not related to the
On 8/6/18, 3:16 PM, Chris Plummer wrote:
On 8/6/18 11:41 AM, Gary Adams wrote:
On 8/6/18, 1:56 PM, Chris Plummer wrote:
On 8/6/18 4:16 AM, Gary Adams wrote:
On 8/3/18, 6:38 PM, Chris Plummer wrote:
Hi Gary,
Overall it looks good.
Is the EventHandler.isDisconnected() check needed
Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev/
Forwarded Message
Subject: RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot
find boolVar with expected value: false
Date: Fri, 25 May 2018 11:35:10 -0400
From: Gary Adams
Reply-To: gary.ad...@
A race condition exists between the debugger and the debuggee.
The first test thread is started with SUSPEND_NONE policy set.
While processing the thread start event the debugger captures
an initial set of thread suspend counts and resumes the
debuggee vm. If the debuggee advances quickly it
ted down this path late Wednesday, but got
sidetracked by a few other things. I can look into it some more if
you'd like.
thanks,
Chris
On 7/19/18 5:08 AM, Gary Adams wrote:
In the successful run below "the first acquire thread suspend counts,
resume,
and the second acquire thread
as started, but before
methodForCommunication(), hoping it will make it so the
ThreadStartEvent can be received and fully processed before the
BreakpointEvent is.
The delay is mostly just a yield so the debugger gets a chance to run.
I think it would be preferable to fix this by doing better
sychro
rty("number");
137display(" got new ThreadStartEvent with
propety 'number' == " + property);
138
139display("..checking up on
EventSet.resume()");
140display("..--> vm.suspend
ore than 2m.
/>>/
/>>/ Lastly, does timeoutFactor impact -waittime? It seems it should be
/>>/ applied to it also. I'm not sure if it is.
/>>/
/>>/ thanks,
/>>/
/>>/ Chris
/>>/
/>>/ On 7/13/18 4:29 AM, Gary Adams wrote:
/>>>/ T
threads disabled, and this
messes up the thread suspend counts. You want to delay 100ms so the
breakpoint event can be processed and threads resumed again (although
I can't see who actually resumes the thread after hitting the
methodForCommunication breakpoint).
Chris
On 7/17/18 8:33 A
to a future issue.
On 8/28/18, 5:23 PM, serguei.spit...@oracle.com wrote:
Hi Gary,
I'd suggest to put the informDebuggeeTestCase(int testCase)
and waitForTestCase(int t) into the test library so that they
are implemented just once.
Thanks,
Serguei
On 8/28/18 05:20, Gary Adams wrote:
I went
cr("%s [%s]", error,
+ full_dump_pathname);
}
}
}
On 8/29/18, 3:49 PM, Chris Plummer wrote:
On 8/29/18 12:42 PM, gary.ad...@oracle.com wrote:
On 8/29/18 3:12 PM, Chris Plummer wrote:
On 8/29/18 11:57 AM, Gary Adams wrote:
Here are the items I'd like to discuss
Looks OK to me.
The extra diagnostic output will be useful to have.
On 8/30/18, 11:08 AM, Gary Adams wrote:
Hi Chris,
It looks good.
Thanks,
Serguei
On 8/29/18 21:19, Chris Plummer wrote:
>/ Hi,
/>/
/>/ Please review the following:
/>/
/>/ https://bugs.openjdk.java.net/bro
Filed:
https://bugs.openjdk.java.net/browse/JDK-8210224
for additional cleanup of the resume tests and better
use of the test library for shared code.
On 8/29/18, 4:16 PM, serguei.spit...@oracle.com wrote:
On 8/29/18 07:46, Gary Adams wrote:
Since the vmTestbase/nsk tests are in need
Should we pull resume001 off the ProblemList.txt?
On 8/30/18, 11:06 AM, Gary Adams wrote:
Filed:
https://bugs.openjdk.java.net/browse/JDK-8210224
for additional cleanup of the resume tests and better
use of the test library for shared code.
On 8/29/18, 4:16 PM, serguei.spit...@oracle.com wrote
enumerate()
that recognizes it is a snapshot of a moving target.
On 9/4/18, 1:51 PM, Chris Plummer wrote:
Hi Gary,
Why has the thread exited if the debuggee is still running?
Chris
On 9/4/18 5:22 AM, Gary Adams wrote:
Here's a quick fix to avoid the NPE using a getThreadGroup() which
cou
DebuggerThreadTarg!
On 9/4/18, 2:16 PM, Chris Plummer wrote:
Can you reproduce the problem? If so, maybe to find out which thread
is a problem you could check for null, print the thread info, and then
fail the test.
Chris
On 9/4/18 11:14 AM, Gary Adams wrote:
I'm not sure which thread exited causes the NPE
commit a
diagnostic fix like the one I suggested and keep an eye on it.
However, it only seems to have failed once due to this reason, so
unless it is a new problem we may never see it again.
Chris
On 9/4/18 11:28 AM, Gary Adams wrote:
I haven't been able to reproduce the problem locally.
Trying lar
,
especially when the end result is still going to be a test failure
that we don't fully understand.
thanks,
Chris
On 9/5/18 7:33 AM, Gary Adams wrote:
The DebuggerThreadTest ensures it is in sync
at the beginning of RunTests with a breakpoint event
in DebuggerThreadTarg ready() method
, so I submitted a mach5 job so
I can
run more tests in batches.
...
On 9/5/18, 2:56 PM, Chris Plummer wrote:
I was thinking something like the resume() call. At the very least
just try setting finishedThreads = 1 to exercise the error handling.
Chris
On 9/5/18 11:49 AM, Gary Adams wrote:
I
:
Ok. Have you found a way to test your changes? Maybe just force or
simulate a failure somehow.
Chris
On 9/5/18 11:26 AM, Gary Adams wrote:
If we go ahead with this proposed fix, the next time it fails
we will have more information about the other threads
captured in the log.
One last
Here's a quick fix to avoid the NPE using a getThreadGroup() which could
be null
if the thread has terminated.
Issue: https://bugs.openjdk.java.net/browse/JDK-8210252
diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java
b/test/jdk/com/sun/jdi/DebuggerThreadTest.java
---
A simple test run using "exclude none" shows 625K methods are being
observed.
The bulk of those methods were due to the last class accessed in the
test - VirtualMachineManager.
It's not important that this particular call is used. The test is simply
demonstrating that
filters work for other
the 8197938 as a dup of 8206007?
Otherwise, the fix looks good to me.
Thank you for the extra testing!
Thanks,
Serguei
On 7/5/18 07:48, Gary Adams wrote:
A simple test run using "exclude none" shows 625K methods are being
observed.
The bulk of those methods were due to the last clas
by?
thanks,
Chris
On 7/5/18 7:48 AM, Gary Adams wrote:
A simple test run using "exclude none" shows 625K methods are being
observed.
The bulk of those methods were due to the last class accessed in the
test - VirtualMachineManager.
It's not important that this particular call is used
This is a simple update to set the jtreg timeout to match the
internal waittime already being used by these vmTestbase/nsk/jdb tests.
Issue: https://bugs.openjdk.java.net/browse/JDK-8206013
Webrev: http://cr.openjdk.java.net/~gadams/8206013/webrev.00/
I've attached the patch for JDK-8206007.
I'll need a sponsor to push the changes.
On 7/5/18, 10:48 AM, Gary Adams wrote:
A simple test run using "exclude none" shows 625K methods are being
observed.
The bulk of those methods were due to the last class accessed in
Here's the starting point for openjdk contributing:
http://openjdk.java.net/contribute/
Here's your post in the mail archives :
http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-July/024441.html
Most people will post a webrev to cr.openjdk.java.net for larger changesets.
Most
Here's a small fix to remove a duplicate InvalidTypeException.
The other reported locations appear to have already been fixed.
Issue: https://bugs.openjdk.java.net/browse/JDK-8167253
Webrev: http://cr.openjdk.java.net/~gadams/8167253/
I finally found some time for some additional testing with the fix below.
I could not force the attach error with windows-x64, but did finally
see some failures with windows-x86.
- I plan to include the ProblemList.txt change for JDK-8057732,
because this change removed the timeout
The main thread in tc02t001 is using a sleep(100) to cause a
monitor contention for the debuggee thread. On some slower
platform builds the main thread continues before the debuggee
thread observes the contention.
Similar to the fix for cm02t001, this is a simple change to increase
the pauses to
choice on how you want to proceed.
Thumbs up from me either way.
Dan
On 10/4/18 2:48 PM, Gary Adams wrote:
fyi - I think JDK-8201603 tc02t001 is suffering from the same issue.
A sleep(100) is used to provoke a contention with the debuggee thread.
If the debuggee is not scheduled qu
Alan suggested in the bug report for the broken link from the jdwp-protocol
spec to the java/lang/ThreadGroup documentation to simply remove the
href link. Another possibility is to simply update the link to include
the java.base
subdirectory.
I don't think the doc structure changes very often
The RedefineCrossEvent test has been on been on the ProblemList for a
very long time.
In the past this test had some dependency on the Java EE modules, but
they were
deprecated for jdk9 and later removed completely in jdk11. This
changeset to restore
it, removes the corba module reference and
and to have a field to store a prompt pattern and
use this pattern (if it was set) when waiting for command to complete. In tests when required we would
set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this
particular step. Do you think it would b
gt;> cases was intentional or not. It may be sufficient to know that the
>>> event fired
>>> without the extra information.
>>>
>>> I don't think a settable prompt is required either. There are
>>> plenty of
>
ing of "java.", "com.", and "sun." prefixed
classes.
--alex
On 10/17/2018 09:46, Gary Adams wrote:
The RedefineCrossEvent test has been on been on the ProblemList for a
very long time.
In the past this test had some dependency on the Java EE modules, but
they wer
I'm not certain that we should be printing locations or prompts for
events when the vm has not been suspended. This looks OK for the
simple test case we are working on here, but in real life there may
be a lot more output produced.
The user has to select a specific thread before additional
,
Chris
thanks,
Chris
On 10/17/18 9:46 AM, Gary Adams wrote:
The RedefineCrossEvent test has been on been on the ProblemList
for a very long time.
In the past this test had some dependency on the Java EE modules,
but they were
deprecated for jdk9 and later removed completely in jdk11
Back in July, I tried to address the jdb output synchronization problem
by buffering the output from commands and events.
http://cr.openjdk.java.net/~gadams/8169718/webrev.01/
The changes were very invasive and only provided a partial solution.
Bottom line for me is the fact that the jdb
.
But it's a nit so looks good to me :)
Jc
On Wed, Oct 17, 2018 at 4:43 AM Gary Adams <mailto:gary.ad...@oracle.com>> wrote:
While investigating other issues with hotswap tests I noticed
2 tests on the Problemlist that I think can be restored.
I have not been able to
No kill002 failures were observed in the next 1000 testruns.
I plan to push the change below and we can see if the exceptions show up in
regular CI test runs.
On 10/16/18, 7:31 AM, Gary Adams wrote:
Still seeing a 1/1000 kill002 failure on solais-sparcv9-debug.
The message waiting
It would be helpful in tracking bugs we are targetting
for the current release, if the bug status was kept up to
date. An unassigned or lower priority bug is a good
candidate to defer. Sometimes bugs are assigned, but
there ends up being resource conflicts to complete
the effort.
I'd like to ask
While investigating other issues with hotswap tests I noticed
2 tests on the Problemlist that I think can be restored.
I have not been able to reproduce the failure with hs102t002
It is marked in the ProblemList as related to JDK-8203350,
but that bug is about hs201t002. It is also marked as
ion of a
simple prompt. There doesn't seem to be much purpose in the first
prompt being printed. You also seem to just be handling the situation
the same as we do for other async commands, so looks good to me.
thanks,
Chris
On 10/15/18 10:44 AM, Gary Adams wrote:
kill ... killing ... killed
This
kill ... killing ... killed
This bug was filed to cover the issue with the kill002 test,
which sometimes did not consume enough of the reply
messages after the wait for the "killed" message is observed.
When a "kill" command is issued it is processed as an asynchronous
command. The "killing"
would suggest to file a separate issue
for that rather than addressing it in the current fix.
Best regards,
Daniil
On 10/22/18, 4:50 AM, "Gary Adams" wrote:
Thanks for making the extra effort to avoid dependency on
the simple prompt matching. One thing to check with t
suggestion of a
simple prompt. There doesn't seem to be much purpose in the first
prompt being printed. You also seem to just be handling the situation
the same as we do for other async commands, so looks good to me.
thanks,
Chris
On 10/15/18 10:44 AM, Gary Adams wrote:
kill ... killing
Filed a bug to track the changes to restore the 2 problem listed tests.
https://bugs.openjdk.java.net/browse/JDK-8213245
Restoring nsk/jvmti/scenarios/hotswap tests from ProblemList.txt
On 10/18/18, 7:51 AM, Gary Adams wrote:
It's not uncommon to have a couple of build directives before a run
temporary file that is blocking the current test
from attaching correctly.
On 10/4/18, 1:49 PM, Gary Adams wrote:
My delay and retry did not fix the problem with permission denied.
When I was diagnosing the problem I instrumented the code
to catch an IOException and call checkPermission to get
m
not count this as an infra
issue. PID files left behind are the fault of the JVM. Maybe there
is something wrong with the cleanup code on solaris, or maybe we
don't clean up on any platform, but cycle through PIDs a lot faster
on solaris.
Chris
On 11/7/18 11:20 AM, Gary Adams wrote:
If there are
Here's a quick fix to add a missing copyright to signature.html.
diff --git
a/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html
b/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html
--- a/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html
+++
. That will
further reduce the likelihood of intermittent failures.
Dan
On 10/4/18 7:39 AM, Gary Adams wrote:
Oops, wrong comment used in the patch.
Fresh patch attached.
On 10/4/18, 7:11 AM, Gary Adams wrote:
Patch attached.
I think one reviewer is sufficient for a trivial patch.
On 10/3/18
1 - 100 of 251 matches
Mail list logo
