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

David Holmes david.holmes at oracle.com
Tue Feb 18 09:39:42 UTC 2014

On 18/02/2014 6:47 PM, Jaroslav Bachorik wrote:
> 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?

I would need to analyze all of the code that accesses it to determine 
that. My initial thought was that it seemed unnecessary and I did look 
at some of the code which seemed to indicate other threads would only 
access it at a safepoint. But there may be other access points that I'm 
not aware of.


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

More information about the hotspot-runtime-dev mailing list