JDK-6972759 : Step over not working after thrown exception and Pop
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6u16,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2010-07-28
  • Updated: 2016-10-21
  • Resolved: 2012-03-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 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
When a program is suspended on a thrown exception and we pop some frames off the stack, subsequent stepping is not reliable.

Steps to reproduce:

1) Compile the attached program
2) In one terminal run:
   java -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:8888,server=y,suspend=y -classpath build/classes test.BadStepTest
3) In a second terminal run:
   jdb -attach 8888
main[1] catch java.lang.NullPointerException
main[1] cont

the program is suspended on an exception: java.lang.NullPointerException
Then do:

main[1] pop
main[1] pop
main[1] step
main[1] next
main[1] next
> Step completed: "thread=main", test.BadStepTest.startTest(), line=24 bci=4
main[1] next
> Step completed: "thread=main", test.BadStepTest.startTest(), line=28 bci=49

Please note that instead of stepping to line 25, program stops at the finally block at line 28. This is unexpected, since user wants to be able to step to the point where the exception was thrown.

We have a real use-case that suffers from this bug at https://netbeans.org/bugzilla/show_bug.cgi?id=188962
Please note that stepping via "step" (Step Into) is possible. Via "next" (Step Over) it's not.

Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/af739d5ab23c
22-03-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/af739d5ab23c
27-01-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/af739d5ab23c
24-01-2012

EVALUATION When an exception is thrown and JVMTI posts the event, the jvmtiThreadState is changed to _exception_detected = true; _exception_caught = false. In this test, the frame is popped twice back to the original call but the jvmtiThreadState remains as above which is now inconsistent with the actual state of the thread. The side effect of this state is that when we do the step over/into of 'item = new Object();' the jdwp agent doesn't enable single-stepping on the method exit event code. The reason is that post_method_exit() code in jvmtiExport.cpp passes the above _exception_detected state to the agent. So the VM continues to execute until it processes the exception in notice_unwind_due_to_exception() where it clears the _exception_detected state. Fix is to clear the jvmtiThreadState exception state back to false in JvmtiThreadState::process_pending_step_for_popframe(). since we have essentially rolled back the actual thread state to that which existed before the exception was thrown. This problem will probably also pop up in the force early return code since it is for the most part the same as pop frame code. Should clear the jvmtiThreadState in process_pending_step_for_earlyret().
12-12-2011