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