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

[serguei.spitsyn at oracle.com]

Jaroslav,

It looks good in general modulo indent comments from Dan.

But I have a doubt that acquiring the JvmtiThreadState_lock is needed
or right thing to do in the JvmtiExport::clear_detected_exception().
It seems, both clear_exception_detected() and set_exception_detected() 
are always
called on current thread and so, it has to be safe to do without 
acquiring any locks.

And I'm repeating my question about pre-integration testing (Dan is 
asking about the same).

Thanks,
Serguei


On 2/14/14 3:07 AM, 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-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140214/be23acd6/attachment.html