RFR 4505697: nsk/jdi/ExceptionEvent/_itself_/exevent006 and exevent008 tests fail with InvocationTargetException
Daniel D. Daugherty
daniel.daugherty at oracle.com
Fri Feb 14 20:33:12 UTC 2014
On 2/14/14 11:46 AM, serguei.spitsyn at oracle.com wrote:
> 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.
My JVM/TI-foo is rusty, but I believe that JvmtiThreadState stuff
can also be queried/modified by other threads so grabbing the
associated lock is a good idea.
> And I'm repeating my question about pre-integration testing (Dan is
> asking about the same).
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev