RFR 4505697: nsk/jdi/ExceptionEvent/itself/exevent006 and exevent008 tests fail with InvocationTargetException (original) (raw)

Jaroslav Bachorik jaroslav.bachorik at oracle.com
Tue Feb 18 00:47:36 PST 2014

Hi David,

On 18.2.2014 06:28, David Holmes wrote:

Hi Jaroslav,

It seems to me that this issue extends to other places in the VM. In particular class initialization in instanceKlass.cpp - anywhere that one exception is "caught" in the VM and then wrapped with, or replaced by, another exception, will only notify JVMTI of the original exception.

Thanks for pointing this out. Turns out there is another location in jvm.cpp which needs the same treatment.

BTW, what is your take on the necessity to grab the JvmtiThreadState_lock before cleaning the detected exception in the jvmti thread state?

-JB-

David On 14/02/2014 9:07 PM, Jaroslav Bachorik wrote: This is a round-0 review request.

The reflection code intercepting the exceptions thrown in the invoked methods does not play nicely with JVMTI (which, in this case, propagates to JDI). The reflection code lacks the traditional error handler - therefore, upon throwing the NumberFormatException, the stack is searched for appropriate handlers and none are found. This leaves the "exceptiondetected" flag set to true while normally it would be reset to false once the exception is handled. The reflection code then goes on and wraps the NumberFormatException into InvocationTargetException and throws it. But, alas, the "exceptiondetected" flag is still set to true and no JVMTI exception event will be sent out. The proposed solution is to call thread->jvmtithreadstate()->clearexceptiondetected() at the appropriate places in the reflection code to reset the "exceptiondetected" flag and enable the InvocationTargetException be properly reported over JVMTI. Issue : https://bugs.openjdk.java.net/browse/JDK-4505697 Webrev: http://cr.openjdk.java.net/~jbachorik/4505697/webrev.00 Thanks! -JB-

More information about the serviceability-dev mailing list