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.
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
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
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
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
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
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...@
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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) :
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:
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/
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 ...
.
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
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
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
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
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"
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
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:
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/
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
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
201 - 251 of 251 matches
Mail list logo
