RFR 4505697: nsk/jdi/ExceptionEvent/_itself_/exevent006 and exevent008 tests fail with InvocationTargetException

David Holmes david.holmes at oracle.com
Tue Feb 18 05:28:15 UTC 2014

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.


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
> "exception_detected" 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 "exception_detected" flag is still set to true
> and no JVMTI exception event will be sent out.
> The proposed solution is to call
> thread->jvmti_thread_state()->clear_exception_detected() at the
> appropriate places in the reflection code to reset the
> "exception_detected" 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 hotspot-runtime-dev mailing list