nds sp06t001Thread {
...
public boolean checkReady() {
// interrupt thread on wait()
synchronized (waitingMonitor) {
interrupt();
}
return true;
}
thanks,
Chris
On 12/13/18 5:25 AM, Gary Adams wrote:
While testing I ran into another of the related failures that
compare
qMethod and qLocation will be skipped, if the threads are not suspended.
And the final comparison that the method was found will only be an error
if the threads are suspended.
Webrev: http://cr.openjdk.java.net/~gadams/8051349/webrev.01/
On 12/12/18, 11:54 AM, Gary Adams wrote:
After som
After some testing with nsk verbose messages enabled,
it is clear that this test is failing in checkThreads when the
location did not match between the call to GetStackTrace
and GetFrameLocation. For the tests that are run when the threads
have not been suspended, there is no guarantee the
On 12/6/18, 7:52 PM, David Holmes wrote:
Hi Gary,
On 6/12/2018 11:27 pm, Gary Adams wrote:
On a local linux-x64-debug build this test consistently runs in less
than 40 seconds.
On the mach5 testing machines there was a large fluctuation in the
time to complete this test.
Since the test runs
I'd like to close this issue as "cannot reproduce".
Issue: https://bugs.openjdk.java.net/browse/JDK-8160380
The original issue was reported 2+ years ago and was
looking for someone to examine the core files to see
if a regression could be identified.
The core files were not preserved, so
On a local linux-x64-debug build this test consistently runs in less
than 40 seconds.
On the mach5 testing machines there was a large fluctuation in the time
to complete this test.
Since the test runs jps with different combinations of arguments, the total
test time is dependent on the number
et accessible step
and set it explicitly.
...
On 11/28/18 11:10 PM, David Holmes wrote:
I've been lurking on this ...
On 29/11/2018 9:41 am, gary.ad...@oracle.com wrote:
On 11/28/18 4:12 PM, Chris Plummer wrote:
On 11/28/18 11:52 AM, Gary Adams wrote:
https://bugs.openjdk.java.net/browse/JDK-8156537
don't update the
variable f making the call useless, no? (The patch in the bug has the
assigments for all the cases),
Jc
On Thu, Nov 29, 2018 at 8:23 AM Gary Adams <mailto:gary.ad...@oracle.com>> wrote:
If a process exits during an attempt to attach to it, the
.
If a process exits during an attempt to attach to it, the .attach_pid file
will not be removed properly, if the path used included symbolic link
traversal,
which is typically done for "/proc//cwd/". Using getCanonicalFile()
before the
initial file is created should prevent this edge case for
with it? I'm assuming no, and therefore it makes sense not
to list it at all.
thanks,
Chris
On 11/28/18 8:33 AM, Gary Adams wrote:
I'd like to close JDK-8176828 as will not fix.
https://bugs.openjdk.java.net/browse/JDK-8176828
This bug was originally thought to be associated with
a regr
I'd like to close JDK-8176828 as will not fix.
https://bugs.openjdk.java.net/browse/JDK-8176828
This bug was originally thought to be associated with
a regression fix in JDK-8176533, but I believe there
is simply a misunderstanding of how the "suspend=y"
behavior is supported for the jdwp
Looks OK to me.
It appears that there were problems in the past with ex03t001
using different GC implementations.
I'd suggest filing a new bug to track moving the test off the ProblemList.
It could be combined with restoring a number of other tests in the
next release timeframe.
On 11/20/18,
Looks OK to me.
On 11/20/18, 9:47 AM, Daniel D. Daugherty wrote:
On 11/20/18 9:34 AM, Simon Tooke wrote:
While compiling the JDK with GCC 8.1, I discovered an invalid bit test
in
test/hotspot/jtreg/serviceability/jvmti/StartPhase/AllowedFunctions/libAllowedFunctions.c.
(status &
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
+++
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
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
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
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
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
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
>
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
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
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
.
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
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
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
,
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
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
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
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"
Patch attached.
I'll need a sponsor for the push.
On 10/8/18, 3:58 PM, serguei.spit...@oracle.com wrote:
Hi Gary,
+1
Thanks,
Serguei
On 10/8/18 11:30, Chris Hegarty wrote:
The updated link looks ok to me.
-Chris
On 8 Oct 2018, at 19:15, Gary Adams wrote:
Alan suggested in the bug
Patch attached.
I think one reviewer is sufficient since this mimics
the cm02t001 bug fix.
On 10/8/18, 3:02 PM, Gary Adams wrote:
Hi Gary,
Looks good. Please add the comment "Wait for contended "sychronized (M)".
thanks,
Chris
On 10/8/18 4:47 AM, Gary Adams wrote:
>
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 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
conditions were reported event.
On 10/4/18, 1:03 PM, Daniel D. Daugherty wrote:
On 10/4/18 1:00 PM, Gary Adams wrote:
On 10/4/18, 12:13 PM, Daniel D. Daugherty wrote:
On 10/4/18 12:04 PM, Gary Adams wrote:
We currently use time factor 4 or 10 to scale up the jtreg tests.
The change I proposed
he problem if it is just duplicating something that is
already in place?
Chris
On 10/4/18 9:48 AM, Gary Adams wrote:
My delay and retry just duplicated the openDoor retry.
The normal processing of FileNotFoundException(ENOENT) is to retry
several times until the file is available.
But the origin
On 10/4/18, 12:13 PM, Daniel D. Daugherty wrote:
On 10/4/18 12:04 PM, Gary Adams wrote:
We currently use time factor 4 or 10 to scale up the jtreg tests.
The change I proposed was already 10x100 = 1000.
Agreed that you are already bumping it up by 10X.
Since this is just a thread
ermissions error.
On 10/4/18, 12:30 PM, Chris Plummer wrote:
Didn't the retry after 100ms delay work? If yes, why would it if the
problem is that a java_pid was not cleaned up?
Chris
On 10/4/18 8:54 AM, Gary Adams wrote:
First, let me retract the proposed change,
it is not the right solution to t
. 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
tected.
There has been some flakiness from the Solaris test machines today,
so I'll continue with the testing a bit longer.
On 10/2/18 3:12 PM, Chris Plummer wrote:
Without the fix was this issue easy enough to reproduce that
you can be sure this is resolving it?
Chris
On 10/2/18 8:1
In TTY.java do you need to force a simple prompt for the
breakpoint event output? What prevents currentThread from
being set at the time you are printing the prompt?
103 // Print the prompt if suspend policy is
SUSPEND_EVENT_THREAD. In case of
104 // SUSPEND_ALL policy this
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, 4:49 PM, Chris Plummer wrote:
Hi Gary,
Although I don't like relying on timer delays for stuff like
there is contention on the monitor. Could you
update the comment to read "// pause to provoke contention on
thread.endingMonitor"
thanks,
Chris
On 10/3/18 11:55 AM, Gary Adams wrote:
While running a block of nsk/jvmti/scenarios tests, I noticed an
occasional failure
for cm02t001 in win
While running a block of nsk/jvmti/scenarios tests, I noticed an
occasional failure
for cm02t001 in windows debug platform. After enabling the nsk verbose
diagnostics and adding a few messages in the main test and the debuggee
thread, it became clear that the missing contention was due to the
Patch attached.
On 10/2/18, 6:00 PM, Alex Menkov wrote:
Looks good to me.
--alex
On 10/02/2018 11:29, Gary Adams wrote:
Looking for one more reviewer before we push this changeset.
On 9/22/18, 6:45 AM, gary.ad...@oracle.com wrote:
This is a very old bug that started off as a closed test
Looking for one more reviewer before we push this changeset.
On 9/22/18, 6:45 AM, gary.ad...@oracle.com wrote:
This is a very old bug that started off as a closed test, but should
have an open review
before it finally gets pushed. Many other jdb bugs will be closed as
duplicates as a
result
Solaris debug builds are failing tests that use the attach interface.
An IOException is reported when the java_pid file is not opened.
It appears that the attempt to attach is taking place too quickly.
This workaround will allow the open operation to be retried
after a short pause.
Webrev:
the reply too early.
Chris
On 9/28/18 11:20 AM, Gary Adams wrote:
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
sometimes it returns the reply too early.
Chris
On 9/28/18 11:20 AM, Gary Adams wrote:
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, Chr
}
So We will get "Wrong number of prompts count" failure?
--alex
On 09/28/2018 04:47, Gary Adams wrote:
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
AM, Gary Adams wrote:
I've been unsuccessful trying to reproduce the failure in hs201t002.
Issue: https://bugs.openjdk.java.net/browse/JDK-8203350
Colleen made a comment on the bug that the reference
from hs201t002a to class hs201t002 might be an issue
for the redefined class.
I found in test
rompt when the count is 0.
Chris
On 9/27/18 11:44 AM, Gary Adams wrote:
Speaking of not being bullet proof, during testing of the fix to
wait for a specific prompt an intermittent failure was observed.
...
Sending command: trace methods 0x2a9
reply[0]: MyThread-0[1]
Sending command: c
ill work no matter what output is
produced by the method enter/exit events.
Chris
On 9/20/18 10:59 AM, Gary Adams wrote:
The test failure has been identified due to the "int[2]"
being misrecognized as a compound prompt. This caused a cont
command to be sent prematurely.
The proposed
I've been unsuccessful trying to reproduce the failure in hs201t002.
Issue: https://bugs.openjdk.java.net/browse/JDK-8203350
Colleen made a comment on the bug that the reference
from hs201t002a to class hs201t002 might be an issue
for the redefined class.
I found in test hs201t001 that an
While looking at some other hotswap tests, I noticed 2 tests on the
ProblemList.
I'm attempting some runs with the tests removed from the list to try
and reproduce the errors locally.
Issues:
https://bugs.openjdk.java.net/browse/JDK-6813266 hs204t001
Patch attached.
Ran another 1000 clean testruns with the sleep(1)
pauses. Restored the sleep(100) for the final patch.
On 9/26/18, 2:12 PM, Chris Plummer wrote:
On 9/26/18 11:07 AM, Gary Adams wrote:
On 9/26/18, 1:40 PM, Chris Plummer wrote:
Hi Gary,
Should the following comment come first
if the bug is easily
reproduced by making is sleep for 1ms instead of 100ms?
That's how I got the problem to reproduce.
Switching to sleep(1) got 5 failures in 300 testruns.
thanks,
Chris
On 9/26/18 7:55 AM, Gary Adams wrote:
A race condition exists in hs203t003 between the main test thread
that I'm
getting rid of the NSK_CPP_STUBs so you could just jump the gun and
remove it directly but this is consistent with the current code base
and my scripts will get to it eventually...).
Thanks,
Jc
On Wed, Sep 26, 2018 at 7:54 AM Gary Adams <mailto:gary.ad...@oracle.com>> wrote:
A race condition exists in hs203t003 between the main test thread and
the processing in callbackFieldAccess processing. The main thread
already includes a polling loop to wait for the redefine class operation
to be performed, but it does not wait for the following suspend thread
operation to be
Looks good to me.
On 9/24/18, 1:25 PM, Daniil Titov wrote:
Hi Alex and Gary,
Please review the updated patch that includes suggested changes.
http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/
Bug: https://bugs.openjdk.java.net/browse/JDK-8163083
Thanks!
--Daniil
On 9/21/18, 3:59 PM,
fine with this fix, but if you have others like it, I'd
suggest putting the "main" thread name in single place, not in
each test that cares about it.
Chris
On 9/20/18 10:54 AM, Gary Adams wrote:
The corrupted output has been identified due to the "Boolean[1]"
be
The test failure has been identified due to the "int[2]"
being misrecognized as a compound prompt. This caused a cont
command to be sent prematurely.
The proposed fix waits for the correct prompt before
advancing to the next command.
Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/
The corrupted output has been identified due to the "Boolean[1]"
being misrecognized as a compound prompt.
The proposed fix waits for the correct prompt before
advancing to the next command.
Webrev: http://cr.openjdk.java.net/~gadams/8208471/webrev/
Issue:
Should sleepTime also be adjusted?
Should sleepTime and timeout be scoped to
just waitForPrompt?
On 9/17/18, 2:26 PM, Gary Adams wrote:
Is the log decoration typical?
98 jdb.log("===");
Is the Utils.adjustTimeout() applied consist
Is the log decoration typical?
98 jdb.log("===");
Is the Utils.adjustTimeout() applied consistently?
e.g. is the timeout passed to waitFor() already adjusted?
If you are promoting log() to be publicly visible, then it
should be used for the other
Patch attached.
On 9/12/18, 3:42 PM, Chris Plummer wrote:
Looks good.
Chris
On 9/12/18 8:20 AM, Gary Adams wrote:
Here's the updated webrev to avoid the NPE, but still
fail the test with more information about the premature
completed threads.
Issue: https://bugs.openjdk.java.net/browse
Patch attached.
On 9/12/18, 3:35 PM, Chris Plummer wrote:
Looks good. I filed JDK-8210668 to address to root issue.
Chris
On 9/12/18 7:27 AM, Gary Adams wrote:
The print statements in the locals002 test have been observed to
interfere
with the output from commands, replies and prompts used
thread is invalidated
On 8/6/18, 12:54 PM, Gary Adams wrote:
On 7/30/18, 12:46 PM, Chris Plummer wrote:
On 7/30/18 12:47 AM, serguei.spit...@oracle.com wrote:
Hi Chris,
Just one quick simple comment below.
On 7/29/18 22:05, Chris Plummer wrote:
Hi Gary,
I updated my changes to do the wait
Here's the updated webrev to avoid the NPE, but still
fail the test with more information about the premature
completed threads.
Issue: https://bugs.openjdk.java.net/browse/JDK-8210252
Webrev: http://cr.openjdk.java.net/~gadams/8210252/webrev.00/
On 9/5/18, 3:16 PM, Gary Adams wrote:
After
The print statements in the locals002 test have been observed to interfere
with the output from commands, replies and prompts used in the
synchronization
of operations between the debugger and debuggee. This change will remove
the
print statements. A follow up bug will be filed for longer term
, 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
,
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
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
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
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
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
---
Nevermind!
ThreadRefence/resume != Eventset/resume
On 8/31/18, 1:06 PM, Gary Adams wrote:
https://bugs.openjdk.java.net/browse/JDK-8072701
JDK-8072701: resume001 failed due to ERROR: timeout for waiting for a
BreakpintEvent
Should we close this as a duplicate?
https
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
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
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
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
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
(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
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
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
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
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
'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
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
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
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
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
101 - 200 of 251 matches
Mail list logo
