> Webrev: http://cr.openjdk.java.net/~jbachorik/4505697/webrev.00
Nice job on such an old bug.
src/share/vm/prims/jvmtiExport.hpp
No comments.
src/share/vm/prims/jvmtiExport.cpp
line 2170: state->clear_exception_detected();
HotSpot indent is two spaces.
src/share/vm/runtime/reflection.cpp
line 948: JvmtiExport::clear_detected_exception((JavaThread*) THREAD);
line 1085: JvmtiExport::clear_detected_exception((JavaThread*) THREAD);
HotSpot indent is two spaces.
So there are two existing tests for this failure mode:
nsk/jdi/ExceptionEvent/_itself_/exevent006
nsk/jdi/ExceptionEvent/_itself_/exevent008
so I'm presuming that you've run the above tests and they are now
happy, but you haven't really stated that. What other pre-integration
testing do you have planned?
Dan
On 2/14/14 4: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-
