RFR 4505697: nsk/jdi/ExceptionEvent/itself/exevent006 and exevent008 tests fail with InvocationTargetException (original) (raw)

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Fri Feb 14 10:46:30 PST 2014

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 "exceptiondetected" 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 "exceptiondetected" flag is still set to true and no JVMTI exception event will be sent out. The proposed solution is to call thread->jvmtithreadstate()->clearexceptiondetected() at the appropriate places in the reflection code to reset the "exceptiondetected" 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

More information about the serviceability-dev mailing list