This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build 200204260820 Let's assume a following code: 1 public class Test { 2 3 public Test() { 4 System.out.println("Test - constructor"); 5 } 6 7 public static void main(String[] args) { 8 System.out.println("First"); 9 System.out.println("Second"); 10 // System.out.println("A"); 11 // System.out.println("B"); 12 System.out.println("Third"); 13 } 14 } Start debugger using F7 (Step into). Debugger stops itself on the line 8. Press F8 (Step Over) and debugger jumps on the next line 9. Now, you add two line (10,11) and invoke a Fix action (Finished Compile before fix [JPDA Debugger].). Line 9 has been still green (possible issue one). If I press F8 key I would expected debugger moves 'green line' to a next line 9, but I get 'Thread main stopped at java.lang.Thread.exit line 545 - unavailable source file' and a 'green line' in missing (issue two). I have available all debugger action (start, stop, step into) except for 'pause' action. I have to stop debugger if I want to use one again.
Please take following sentece instead of it that was in previous post <snip>If I press F8 key I would expected debugger moves 'green line' to a next line ***10***,<snip>
This bug may be split into three separate issues: - an attempt to perform "step over" on an obsolete call stack frame of a redefined class causes "step out" - if "public static void main(String[] args)" is the only method call on a call stack, leaving this method does not cause exit of JVM, the frame is replaced with frame "Thread.exit()" instead - obsolete call stack frames use new line numbers (JDK bug #4660756: "TTY: Need to clear source cache after doing a redefine class").
I forgot to mention that none of the three issues is caused by NetBeans code.
Detailed evaluation: "Start debugger using F7 (Step into). Debugger stops itself on the line 8. Press F8 (Step Over) and debugger jumps on the next line 9. Now, you add two lines (10, 11) and invoke a Fix action. Line 9 has been still green (possible issue one)." *** This is the correct behaviour. The debugger continues in debugging the original bytecode (until the method is re-entered). It is at line 9 which is correct (class redefinition does not move the position). "If I press F8 key I would expected debugger moves 'green line' to a next line 10, but I get 'Thread main stopped at java.lang.Thread.exit line 545 - unavailable source file' and a 'green line' is missing (issue two)." *** This following happens: - JDK bug 4689395 ("step over" after a class is redefined acts like "step out") causes that debugger jumps out of method 'main' - JDK bug/feature(?) causes that when the application's last call stack frame is left as a result of action "step over", the debuggee jumps to method 'java.lang.Thread.exit()' (call stack frame "Test.main(String args[])" is _replaced_ with frame "Thread.exit()"). This strange behaviour have not yet been reported to the JDK team. This behaviour is not specific to operations fix/pop. "I have available all debugger actions (start, stop, step into) except for 'pause' action. I have to stop debugger if I want to use one again." *** This is a bug in NetBeans. Again, it is not specific to operations fix/pop. It would happen even if the class were not redefined (just repeatedly press F8 after the session is started).
I have created two separate bug reports instead of this one. See: bug 25042 - Debugger jumps to "java.lang.Thread.exit()". bug 25043 - "Step Over" acts like "Step Out" after "Fix" without pop *** This issue has been marked as a duplicate of 25042 ***
25042 has been closed, but described problem still occures in during F7C.
*** Issue 26672 has been marked as a duplicate of this issue. ***
Added following note to 3.4 README 22856 Description : The Fix and Continue feature does not work correctly if you change code in the main method. You are not given the option to use modified code. The class is recompiled, but it is not possible to continue debugging. Workaround : Make necessary changes in the main method and then restart the debugger session.
JDk bugs are fixed but not integrated in JDK1.4.0_01 & 1.4.1 beta. They should be fintegrated to 1.4.2...
Bug report #25042 was closed but the reported behaviour was not fixed. So I reopen #25042 and again resolve this bug as a duplicate of it. It is not the best solution (it would be best to resolve this issue as a compound issue of another bugs) but #25042 is the only issue (of the three described sub-issues) we can fix in NetBeans. *** This issue has been marked as a duplicate of 25042 ***
removing RELNOTE keyword, since the bug this bug is based on is fixed for NB 3.5
Resolved for 3.3.x or earlier, no new info since then -> closing.