RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112)

[serguei.spitsyn at oracle.com]

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.spitsyn at 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
>>