Serguei,
Thank you!
Fix looks good for me.
-Dmitry
On 2014-10-29 17:35, serguei.spit...@oracle.com wrote:
> 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.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
>>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
