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.
It seems that step out action leaves some hidden breakpoint. Then debugger unexpectedly stops there. To repeat: - create sample 'Anagram game' project - add breakpoint to a method in WordLibrary class (e.g. line 117) - start debugger, guess word and wait until it stops at breakpoint - step out repeatedly until debugger continues - guess word again. Now debugger stops at line 120 in Anagrams.java where it previously leaves the source code. I expect it should stop at breakpoint. Output from debugger console: Listening on 3749 User program running Breakpoint hit at line 117 in class com.toy.anagrams.lib.WordLibrary by thread AWT-EventQueue-0. Thread AWT-EventQueue-0 stopped at WordLibrary.java:117. User program running Thread AWT-EventQueue-0 stopped at WordLibrary.java:144. User program running Thread AWT-EventQueue-0 stopped at Anagrams.java:207. User program running Thread AWT-EventQueue-0 stopped at Anagrams.java:16. User program running Thread AWT-EventQueue-0 stopped at Anagrams.java:121. User program running Thread AWT-EventQueue-0 stopped at Anagrams.java:120. Build 20050203-1319, JDK1.5.0_02, WindowsXP.
Increasing to P3, since internal users have problems with staled hidden breakpoints. This needs to be explored...
*** Issue 86365 has been marked as a duplicate of this issue. ***
From the analysis of almost identical issue #86365 follows that this is because of smart-stepping. The last step out request is remembered by smart-stepping framework and as soon as you enter your project again, the program is stopped. To solve this, we have to check whether there is some code to stop at, on the stack. And if not, then abandon the step out request.
Well, this idea is *very* problematic to implement, since smart-stepping API takes thread instead of a stack frame. It makes no sense, because it needs the stack frame in fact. We'll likely have to change the API to be able to fix this :-( Or find some other way....
Also step over behaves this way - see issue #99354.
Since there is almost identical report P3 #99354, decreasing this back to P4. I do not want to mark it as duplicate since there are well documented repro-cases.
Changing TM for open issues.
It looks like this brings confusion to debugger users, therefore upgrading to P3. I'll prepare an API change for smart-stepping API...
After this is fixed, we should check that it solves bug #99354 as well.
This seems to be fixed in NB 7.0. When Step Out or Step Over action is performed, I can not reproduce this behavior any more. The execution is correctly suspended on the breakpoint. However, this bug can still be reproduced with Step Into. There's issue #66560 already for this.