RFR 4505697: nsk/jdi/ExceptionEvent/_itself_/exevent006 and exevent008 tests fail with InvocationTargetException
jaroslav.bachorik at oracle.com
Tue Feb 18 08:47:36 UTC 2014
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?
> 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
More information about the hotspot-runtime-dev