United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6972759 Step over not working after thrown exception and Pop
6972759 : Step over not working after thrown exception and Pop

Details
Type:
Bug
Submit Date:
2010-07-28
Status:
Closed
Updated Date:
2012-04-10
Project Name:
JDK
Resolved Date:
2012-03-24
Component:
hotspot
OS:
linux,generic
Sub-Component:
jvmti
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u16,7
Fixed Versions:
hs23

Related Reports
Backport:
JDK-2220626 - Step over not working after thrown exception and Pop
Backport:
JDK-2220562 - Step over not working after thrown exception and Pop
Relates:
JDK-6742507 - Problem with stepping after class redefine

Sub Tasks

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
2012-03-22 
EVALUATION

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

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/af739d5ab23c
2012-01-24 
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().
2011-12-12


Hardware and Software, Engineered to Work Together