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

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Wed Oct 29 14:09:14 UTC 2014


Dan,

I do not have a scenario for non-anonymous class case while they should 
exist.
The anonymous scenario was well reproducible in a range of the jdk8 ea 
builds.
However, it is not as such anymore.
I was not able to reproduce it in jdk9, nor 8u40.
But I believe the shutdown race issue is still there and can hit anytime.

Thanks,
Serguei


On 10/29/14 6:46 AM, Daniel D. Daugherty wrote:
> Serguei,
>
> Do you have a scenario for the non-anonymous class case? This bug
> (6988950) has been around much longer than anonymous classes...
>
> Dan
>
>
> On 10/28/14 7:11 PM, 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
>>
>



More information about the serviceability-dev mailing list