JDK-4505697 : nsk/jdi/ExceptionEvent/_itself_/exevent006 and exevent008 tests fail with InvocationTargetException
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 1.4.0,1.4.2,5.0,6,7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2001-09-21
  • Updated: 2018-07-26
  • Resolved: 2014-02-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u171Fixed 8u60Fixed 9 b04Fixed
Related Reports
Relates :  
Description
Test : nsk/jdi/EventRequestManager/createExceptionRequest/crexreq006
TestBase : testbase_nsk.v14r07
Mode : default

Other tests affected :
nsk/jdi/EventRequestManager/createExceptionRequest/crexreq008

Steps to reproduce :
1. cd /net/sqesvr.eng/export/vsn/GammaBase/Bugs/{BugID}
2. sh doit {JAVA}

OR

1. cd /net/sqesvr.eng/export/vsn/GammaBase/Bugs/{BugID}
2. export arch=${ARCH}
3. ${JAVA} -showversion nsk.jdi.EventRequestManager.createExceptionRequest.crexreq006 -arch=$arch -waittime=2 -debugee.vmkind=java -debugee.vmkeys=-client

Output :
java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b80)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b80, mixed mode)

debugee.stderr> Exception in thread "main" java.lang.reflect.InvocationTargetException
debugee.stderr>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
debugee.stderr>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:42)
debugee.stderr>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:28)
debugee.stderr>         at java.lang.reflect.Method.invoke(Method.java:313)
debugee.stderr>         at nsk.jdi.EventRequestManager.createExceptionRequest.crexreq006t.communication(crexreq006t.java:42)
debugee.stderr>         at nsk.jdi.EventRequestManager.createExceptionRequest.cr
exreq006t.main(crexreq006t.java:22)
debugee.stderr> Caused by: java.lang.NumberFormatException: oops!
debugee.stderr>         at java.lang.Integer.parseInt(Integer.java:429)
debugee.stderr>         at java.lang.Integer.parseInt(Integer.java:479)
debugee.stderr>         at nsk.jdi.EventRequestManager.createExceptionRequest.crexreq006tException.crexreq006traiseEx(crexreq006t.java:52)
debugee.stderr>         ... 6 more
# ERROR: TEST FAILED: uncaught exception java.lang.reflect.InvocationTargetException was not reported by the debugger
STATUS=97


Name: dkR10014			Date: 01/09/2002


Due to fix of 4615225 the tests were moved to new location:
 nsk/jdi/ExceptionEvent/_itself_/exevent006
 nsk/jdi/ExceptionEvent/_itself_/exevent008

  


======================================================================

Comments
Affects JDK-7 SQE VM nightly. Please consider for backport.
01-04-2016

The fix is asserted by the tests mentioned in the bug description.
12-05-2015

Currently the reflection code checks for an exception being thrown from the invoked method - it then clears the pending exception via ((ThreadShadow*)THREAD)->clear_pending_exception() and wraps the caught exception into a new InvocationTargetException instance which is then thrown at the caller. And here comes the trick - JVMTI keeps its own flag indicating an exception has been thrown on a certain thread. And it issues notification only if the thread hasn't been set yet; and at the same time the flag is set. The JVMTI flag is reset when an exception becomes caught or the thread with the exception just exits. When reflection is involved neither happens. The reflection code needs to play nicely with JVMTI and clean the JVMTI's flag too.
10-02-2014

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.
06-02-2014

ILW=MMM=P3 Monitoring exceptions via debugger is less reliable for exceptions generated in methods called via reflection. Workaround is not to use reflection.
06-02-2014

Sorry missed the part where these tests were renamed which explains why I couldn't find them in testbase. Updating the bug to a better title.
21-08-2013

These tests have been removed.
20-08-2013

EVALUATION The test generates a NumberFormatException in a method invoked via reflection. The reflection mechanism wraps the NumberFormatException in an InvocationTargetException which is how the invoked method exits. jpda treats the NumberFormatException as an 'uncaught' exception; it is reported to the debugger if 'uncaught' is selected when the ExceptionEventRequest is created. jpda doesn't report the InvocationTargetException at all, no matter whether 'caught' or 'uncaught' is selected in the request. It is as if the reflection mechanism gets the NumberFormatException without actually catching it, and generates the InovationTargetException wrapper exception without going thru the normal 'throw' mechanism which would cause jpda to notice it and report it. I wonder if this is related to 4361993 - Convert com.sun.jdi.InvocationExcaption to use exception chaining ###@###.### 2001-12-03
03-12-2001