JDK-4278333 : Regression test com/sun/jdi/StepTest.java Failing
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.3.0,1.3.1_01
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,windows_nt
  • CPU: generic,x86
  • Submitted: 1999-10-05
  • Updated: 2000-09-11
  • Resolved: 2000-09-11
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.
Other
1.3.0 sol-beta2Fixed
Related Reports
Duplicate :  
JDK-4342204 - unix: regression test StepTest fails
Duplicate :  
JDK-4376679 - Regression test com/sun/jdi/StepTest.java Failing
Relates :  
JDK-4331369 - jdb: it needs to call 'step' twice to step from brkpoint in main
Relates :  
JDK-4409241 - MethodExitEvents disappear when Object-Methods are called from main (#108885)
Relates :  
JDK-4337667 - crash (sig 11) on second invocation of a breakpoint
Relates :  
JDK-4289109 - break points are not reported as expected
Description
naveena.suryadevara@Eng 1999-10-05

JDKversion: kestrel I-FCS
Regression test: com/sun/jdi/StepTest.java

NOTE: This test fails on both win32 and solaris.
Test results:
#section:main
----------messages:(3/146)----------
command: main StepTest2 min 4 MethodCalls
reason: User specified action: run main StepTest 2 min 4 MethodCalls 
elapsed time (seconds): 13.921
----------System.out:(16/595)----------
Java HotSpot(TM) Client VM warning: Setting of property "java.compiler" is ignored
JVM version:1.3.0
JDI version: 1.3
JVM description: Java Debug Interface (Reference Implementation) version 1.3 
Java Debug Wire Protocol (Reference Implementation) version 1.0
JVM Debug Interface version 1.0
JVM version 1.3.0 (Java HotSpot(TM) Client VM, interpreted mode)
Step #1complete at go:48 (1)
Step #2complete at go:48 (1)
Called instanceCaller
Called staticCallee
Called instanceCallee
Called instanceCallee
Step #3complete at go:49 (4)
Step #4complete at go:49 (5)
Called staticCaller
----------System.err:(12/862)----------
java.lang.Exception: Didn't step far enough (MethodCalls.staticCaller(MethodCalls)+0 in thread instance of java.lang.Thread(name='main', id=1))
	at StepTest.runTests(StepTest.java:108)
	at JDIScaffold.startTests(JDIScaffold.java:185)
	at StepTest.main(StepTest.java:49)
	at java.lang.reflect.Method.invoke(Native Method)
	at javasoft.sqe.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:485)

JavaTest Message: Test threw exception: java.lang.Exception: Didn't step far enough (MethodCalls.staticCaller(MethodCalls)+0 in thread instance of java.lang.Thread(name='main', id=1))
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.Exception: Didn't step far enough (MethodCalls.staticCaller(MethodCalls)+0 in thread instance of java.lang.Thread(name='main', id=1))
result: Failed. Execution failed: `main' threw exception: java.lang.Exception: Didn't step far enough (MethodCalls.staticCaller(MethodCalls)+0 in thread instance of java.lang.Thread(name='main', id=1))


test result: Failed. Execution failed: `main' threw exception: java.lang.Exception: Didn't step far enough (MethodCalls.staticCaller(MethodCalls)+0 in thread instance of java.lang.Thread(name='main', id=1))
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kest-sol-beta2 FIXED IN: kest-sol-beta2 INTEGRATED IN: kest-sol-beta2 VERIFIED IN: merlin-beta
14-06-2004
EVALUATION gordon.hirsch@eng 1999-10-05 This seems to happen only with the hotspot VM, so it is likely a problem with the hotspot JVMDI implementation. gordon.hirsch@eng 1999-10-15 The problem seems to happen when instructions are rewritten by the interpreter. The at_safepoint function is called twice for those instructions, causing duplication of events. This happens with both line and instruction stepping. jvmdi can filter these duplicates by tracking the current location on a per-thread basis while stepping and/or breakpoints are enabled. I have a solution partially coded. mohammad.gharahgouzloo@Eng 1999-11-03 The bug happens with build on 11-02-99. I just had one question. Is it a bug in the debugger that even if you specify -classic the hotspot jvm is loaded? peter.kessler@Eng 2000-01-04 If the interpreter rewrites instructions, what does the user see when they are single-bytecode-stepping? If there was an ALOAD;GETFIELD and we turn it into some fancy field-fetch bytecode, what good is it going to do to report the fancy field-fetch as the bytecode to the user? They aren't going to know what it is: their GUI debugger won't know what it is. I think that debugging needs to turn off instruction rewriting. That might also avoid the problem reported in this bug. peter.kessler@Eng 1999-11-04 The test is in error. The VM is partly at fault, too, which confuses things. What happens is that the first time an instruction is executed with unresolved references in the constant pool, the interpreter resolves the constant pool entries and rewrites the instruction to say it doesn't have to do constant pool resolution; then it reexecutes the resolved instruction. The problem is that in general execution of a single instruction may cause the VM to execute other Java instructions as part of the runtime. Lars points out that object allocation may cause registration of finalizers in Java code. HotSpot could be better about not breakpointing when an unresolved instruction was executed. The question is whether you want to see the work that's done on behalf of an instruction before or after you hit the breakpoint at the instruction? This is a problem for the test because it expects that 49 single steps will get it to a particular place in the code. In practice I don't think this will confuse humans using a debugger. I recommend we declare the test to be in error, and that we document the re-execution property of the HotSpot VM, and that we try to figure out something reasonable to do for Merlin. gordon.hirsch@eng 2000-01-04 If the execution of instruction leads to other the execution of other Java instructions, then control should pass to those instructions. If an instruction is simply rewritten, there is no value to generating multiple step events. It may not confuse users for long, but it will likely confuse them at first and later annoy them. A careful and complete implementation would hide the rewrites. So, I disagree that the test is incorrect. peter.kessler@Eng 2000-01-04 In this test, between the first and second executions of the instruction the HotSpot VM goes off and calls java.lang.ClassLoader.loadClassInternal to do some security checking as required by the new security model. That method is a Java method, so Java instructions are executed during the resolution of the original instruction. I don't know if classic has been changed to call ClassLoader.loadClassInternal, or if it does class loading as lazily as HotSpot. I agree that a better implementation would hide simple rewrites, and I think your fixes for HotSpot do that. In the cases where the VM calls other Java code, I think single-stepping should show that code, and it doesn't seem so bad to tell the user that they are back to the original instruction by stopping there, again, as you execute it after resolution is complete. This will be a problem for any code that causes class loading: including calling static methods or accessing static fields of classes that are not yet loaded. daniel.daugherty@Eng 2000-05-23 See the evaluation of 4331369 for additional information on how single stepping can be hidden for Java code that executed on behalf of other Java code. Also there was a problem with repeated breakpoint events due to the switch to single stepping mode. daniel.daugherty@Eng 2000-05-24 The following test: /opt/java1.3/bin/java StepTest 2 line 2 MethodCalls does the equivalent of two jdb "next" commands after breakpointing in the test's go() method: void go() throws Exception { instanceCaller(); staticCaller(this); } On Solaris, the test is failing because the frame pop event is not posted after the return from instanceCaller(). Consequently, the next/step-over simply runs to the end of the program. daniel.daugherty@Eng 2000-05-26 The fix for 4331369 solved the Win32 failure for this bug. However, two of four tests still fail on Solaris with the java command, but not with the java_g command. So this bug has to be chased on Solaris and without a debug java command; the worst possible combination. The first test is failing because the frame pop event is not posted after the return from instanceCaller(). Consequently, the next/step-over command simply runs to the end of the program. The frame pop event is not posted because the frame tracking information gets corrupted. When the frame pointer gets corrupted to zero, the frame pop event search logic terminates too early. I have observed corruption to invalid, non-zero values on java_g, but that corruption doesn't cause a failure. I found the reason for the "corruption". On Win32 frame objects are pretty much static. If you have one, you can use for it for JVM/DI purposes even after the frame has become stale, i.e., been popped and the stack reused. On SPARC, the frame pointer in the frame object is computed at run-time from an offset into the stack. The frame object is stable as long as the frame is active and even when the frame is first popped. However, when the stack referenced by the now popped frame is reused, the frame pointer value gets trashed. I looked into how to preserve a static view of a frame for JVM/DI's use and while doing so I noticed that the JvmdiFramePop class could be lightened up quite a bit. We carry around the frame object when all we really need is a list of frame pointers (static ones, of course :-)). It appears that this class was cloned from the JvmdiBreakpoint class and really doesn't need to have all that functionality. While this rework of JvmdiFramePop would solve the stale frame problem (and should be done in the future), it dawned on me to investigate why we had a stale frame object on the list. I discovered that NotifyFramePop() added entries to the frame pop list even when JVMDI_EVENT_FRAME_POP was disabled. In this case, the frame pop can happen but the frame is not removed from the list because we don't post a frame pop event. The stale frame causes grief for later frame pop processing when it's frame pointer evolves into a NULL.
11-06-2004
SUGGESTED FIX peter.kessler@Eng 2000-01-04 We need to add something to the README document for HotSpot that points out that HotSpot may re-execute bytecodes in some circumstances and that this may be visible from debuggers. daniel.daugherty@Eng 2000-05-26 See the suggested fix for 4331369 for details on how repeated single step events was fixed. I have a better idea for a fix... daniel.daugherty@Eng 2000-05-26 See attached webrev.tar file for changes that fix the missing frame pop event problem. mandy.chung@eng 2001-03-01 A refinement to this fix is made for 4409241. In jvmdi::post_method_exit_event(), only reset method_exit_on flag if METHOD_EXIT event is disabled.
01-03-2001