RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface
David Holmes
david.holmes at oracle.com
Tue Sep 5 04:43:57 UTC 2017
Hi Serguei,
This looks good to me. One not below.
On 2/09/2017 6:30 PM, serguei.spitsyn at oracle.com wrote:
> Please, review a fix for:
> https://bugs.openjdk.java.net/browse/JDK-8177901
>
> Webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.1
src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
+ // Release commandLoop vmDeathLock if necessary
+ void commandLoop_exitVmDeathLockOnError(void);
+ commandLoop_exitVmDeathLockOnError();
The declaration should be in the eventHelper.h header file. It looks
really odd to declare the function then call it.
Thanks,
David
-----
>
> Summary:
>
> The approach to fix this is to introduce a new lock vmDeathLock in
> eventHelper.c
> and use it to sync the commandLoop with the JVMTI event callback
> cbVMDeath
> the same way as it was done for debugLoop_run.
> (see the fix of: https://bugs.openjdk.java.net/browse/JDK-8134103)
>
> One potential issue with it is that the commandLoop() transitively
> uses some helper
> functions (e.g. from util.c) that use the macro EXIT_ERROR, and so,
> can abort.
> It seems, in such a case the vmDeathLock will remain locked, and so,
> the cbVMDeath() will block on it causing a deadlock.
> Note, that these helper functions can be also called from different
> contexts/threads
> (not from the commandLoop thread only). In such contexts the
> commandLoop vmDeathLock
> is not being entered, and so, should not be exited.
>
> To fix this potential issue, new function,
> commandLoop_exitVmDeathLockOnError(),
> is introduced, and it is called from the debugInit_exit().
> The commandLoop_exitVmDeathLockOnError() always checks if current thread is
> the commandLoop thread and only in such a case unlocks the vmDeathLock.
>
> Testing:
> Ran the nsk.jdi, nsk.jdwp and jtreg jdk_jdi for both release and
> fastdebug builds.
> All tests are passed.
>
> Thanks,
> Serguei
>
More information about the serviceability-dev
mailing list