RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112)
Dmitry Samersoff
dmitry.samersoff at oracle.com
Wed Oct 29 13:59:32 UTC 2014
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
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
More information about the serviceability-dev
mailing list