2-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112)

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Thu Oct 30 19:07:53 UTC 2014


Thanks, Dmitry!
Serguei

On 10/30/14 4:16 AM, Dmitry Samersoff wrote:
> Serguei,
>
> Looks good for me!
>
> -Dmitry
>
> On 2014-10-30 04:05, serguei.spitsyn at oracle.com wrote:
>> The updated webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/
>>
>>
>> The changes are:
>>    - added a comment recommended by Staffan
>>    - removed the ignore_wrong_phase() call from function classSignature()
>>
>> The classSignature() function is called in 16 places.
>> Most of them do not tolerate the NULL in place of returned signature and
>> will crash.
>> I'm not comfortable to fix all the occurrences now and suggest to return
>> to this
>> issue after gaining experience with more failure cases that are still
>> expected.
>> The failure with the classSignature() involved was observed only once in
>> the nightly
>> and should be extremely rare reproducible.
>> I'll file a placeholder bug if necessary.
>>
>> Thanks,
>> Serguei
>>
>> On 10/28/14 6: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