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

[serguei.spitsyn at oracle.com]

On 2/14/14 12:33 PM, Daniel D. Daugherty wrote:
> On 2/14/14 11:46 AM, serguei.spitsyn at oracle.com wrote:
>> 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.
>
> 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.

The lock synchronization is cooperative.
It does not help much if the lock is not acquired in other places.
I can be wrong, but I've not found yet any place in the code where the
clear_exception_detected() and set_exception_detected() are called
under protection of the JvmtiThreadState_lock.

Thanks,
Serguei

>
> Dan
>
>
>>
>> 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/6fdcf9dd/attachment.html