Staffan,
Thank you for the review!
I agree that maybe it'd make sense to ignore in all functions.
But I'm trying to be careful - let's see if this approach works first.
It is a good idea to add a comment.
Thanks,
Serguei
On 10/29/14 4:52 AM, Staffan Larsen wrote:
This looks good - and thanks for the detailed description!
My only comment is that you chose to ignore the error in only some of the
methods - I assume these were the methods where you have encountered a problem
in. Should we write a comment about that, or should we ignore the error in all
methods?
/Staffan
On 29 okt 2014, at 02:11, serguei.spit...@oracle.com wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6988950
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/
Summary:
The failing scenario:
The debugger and the debuggee are well aware a VM shutdown has been
started in the target process.
The debugger at this point is not expected to send any commands to the
JDWP agent.
However, the JDI layer (debugger side) and the jdwp agent (debuggee side)
are not in sync with the consumer layers.
One reason is because the test debugger does not invoke the JDI method
VirtualMachine.dispose().
Another reason is that the Debugger and the debuggee processes are uneasy
to sync in general.
As a result the following steps are possible:
- The test debugger sends a 'quit' command to the test debuggee
- The debuggee is normally exiting
- The jdwp backend reports (over the jdwp protocol) an anonymous class
unload event
- The JDI InternalEventHandler thread handles the ClassUnloadEvent event
- The InternalEventHandler wants to uncache the matching reference type.
If there is more than one class with the same host class signature, it
can't distinguish them,
and so, deletes all references and re-retrieves them again (see
tracing below):
MY_TRACE: JDI: VirtualMachineImpl.retrieveClassesBySignature:
sig=Ljava/lang/invoke/LambdaForm$DMH;
- The jdwp backend debugLoop_run() gets the command from JDI and calls
the functions
classesForSignature() and classStatus() recursively.
- The classStatus() makes a call to the JVMTI GetClassStatus() and gets
the JVMTI_ERROR_WRONG_PHASE
- As a result the jdwp backend reports the JVMTI error to the JDI, and
so, the test fails
For details, see the analysis in bug report closed as a dup of the bug
6988950:
https://bugs.openjdk.java.net/browse/JDK-8024865
Some similar cases can be found in the two bug reports (6988950 and
8024865) describing this issue.
The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error as it is
normal at the VM shutdown.
The original jdwp backend implementation had a similar approach for the
raw monitor functions.
Threy use the ignore_vm_death() to workaround the JVMTI_ERROR_WRONG_PHASE
errors.
For reference, please, see the file: src/share/back/util.c
Testing:
Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests
Thanks,
Serguei
