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

[Jaroslav Bachorik]

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
>> "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-