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

[serguei.spitsyn at oracle.com]

Dmitry,

Yes, it will return NULL if the case of JVMTI_ERROR_WRONG_PHASE error.
It is Ok for the getMethodClass() as the NULL return value listed in the 
comment.
It seems to be Ok for other two uses of the methodClass().

Thanks!
Serguei

On 10/29/14 6:59 AM, Dmitry Samersoff wrote:
> Serguei,
>
> What happens in a caller function if we ignore the error?
>
> e. g. getMethodClass has the code:
> ...
>
>      error = methodClass(method, &clazz);
>      if ( error != JVMTI_ERROR_NONE ) {
>          EXIT_ERROR(error,"Can't get jclass for a methodID, invalid?");
>          return NULL;
>      }
>      return clazz;
>
> after the fix it probably will return NULL. Is it correct?
>
> -Dmitry
>
> On 2014-10-29 04: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
>>
>