RFR 4505697: nsk/jdi/ExceptionEvent/_itself_/exevent006 and exevent008 tests fail with InvocationTargetException
David Holmes
david.holmes at oracle.com
Mon Feb 17 21:28:15 PST 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.
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
> "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 serviceability-dev
mailing list