On 12/02/2019 10:40 pm, Gary Adams wrote:
On 2/12/19, 7:14 AM, David Holmes wrote:
On 12/02/2019 10:11 pm, Gary Adams wrote:
Yes, see the revised webrev, we do have to guard against
multiple calls to dispose, e.g. catch and ignore VMDisconnectException.
We don't need to guard against a null vm.
Hi Gary,
+1
Thanks,
Serguei
On 2/12/19 11:24 AM, Chris Plummer wrote:
Hi Gary,
The changes look good.
thanks,
Chris
On 2/12/19 11:04 AM, gary.ad...@oracle.com wrote:
Successfully ran 100X {solaris,macosx,windows,linux} debug builds
for the tests impacted by Debugee.endDebugee() processing
Hi Gary,
The changes look good.
thanks,
Chris
On 2/12/19 11:04 AM, gary.ad...@oracle.com wrote:
Successfully ran 100X
{solaris,macosx,windows,linux} debug builds
for the tests impacted by
Deb
Successfully ran 100X {solaris,macosx,windows,linux} debug builds
for the tests impacted by Debugee.endDebugee() processing.
|test/hotspot/jtreg/vmTestbase/nsk/jdi
test/hotspot/jtreg/vmTestbase/vm/mlvm test/jdk/com/sun/jdi|
On 2/12/19 7:40 AM, Gary Adams wrote:
On 2/12/19, 7:14 AM, David Holm
On 2/12/19, 7:14 AM, David Holmes wrote:
On 12/02/2019 10:11 pm, Gary Adams wrote:
Yes, see the revised webrev, we do have to guard against
multiple calls to dispose, e.g. catch and ignore VMDisconnectException.
We don't need to guard against a null vm. That would only exist if
the vm was never
On 12/02/2019 10:11 pm, Gary Adams wrote:
Yes, see the revised webrev, we do have to guard against
multiple calls to dispose, e.g. catch and ignore VMDisconnectException.
We don't need to guard against a null vm. That would only exist if
the vm was never initialized and we were shutting down.
O
Yes, see the revised webrev, we do have to guard against
multiple calls to dispose, e.g. catch and ignore VMDisconnectException.
We don't need to guard against a null vm. That would only exist if
the vm was never initialized and we were shutting down.
There is a race condition between the debugge
Hi Gary,
On 12/02/2019 8:08 pm, gary.ad...@oracle.com wrote:
The recent change to JDK-8068225 changed the order of operations
in Debugee.endDebugee() to wait for the debugee to exit before
disposing of the vm on the debugger side of the connection.
For the tests based on JDIBreakpointTest the de
Have to guard against multiple calls to dispose.
Revised webrev: http://cr.openjdk.java.net/~gadams/8218754/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8218754
On 2/12/19, 5:08 AM, gary.ad...@oracle.com wrote:
The recent change to JDK-8068225 changed the order of operations
The recent change to JDK-8068225 changed the order of operations
in Debugee.endDebugee() to wait for the debugee to exit before
disposing of the vm on the debugger side of the connection.
For the tests based on JDIBreakpointTest the debuggee exit
status is not used and the tests relied on the
debu
10 matches
Mail list logo
