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 # : NB20050329 ] [ JDK VERSION : 1.5.0_02 ] When I apply code changes the debugger steps bahave different from before applying changes. Some step-over steps have to be done 2, 3 or even 4 times before the debugger proceeds to the next line.
Is this reproducible? Can you send your test-case?
Problem happens each and everytime, regardless of source file. You should be able to reproduce this with any source file. If not, then I will see if I can make a small test case.
Please, send the test-case & mainly steps to reproduce. Thanks a lot!
It is difficult for me to create one particular test case. All I know is that the current state of the debugger is unacceptable. After a "Fixe Changes" the debuger acts unreliable: Debugger sometimes jumps to a breakpoint where there is no breakpoint at all, for example when I stop an application. This happens consistently until I reboot the IDE.
Two people tried to reproduce this issue without any success. We will need exact step by step description how to reproduce. Please provide *any* details - how you start debugger, how many sessions is running, how you step through the code, how many breakpoints, what sources are used for debugging etc. Everybody has own routine to work with UI, so it's really important to describe yours. Thanks.
One scenario I can consistently reproduce is the following. Put a breakpoint somewhere in your code. Debugger stops at breakpoint. Now remove a line following the breakpoint. Compile > Apply Changes Now you will see that you have to step twice on the original breakpoint.
After "Apply Changes" if the debugging continues in the method that was changed, old code is being executed until you exit the changed method. In latest builds, debugger automatically pops the modified method on stack so that the new code is entered. So this particular case should work fine, although the behavior might not be expected. It would be best to show always the right source for the code being debugged. We need to make a special editor view for that, because the debugged code might not correspond to the current source on disk.
*** Issue 58980 has been marked as a duplicate of this issue. ***
*** Issue 66254 has been marked as a duplicate of this issue. ***
*** Issue 67579 has been marked as a duplicate of this issue. ***
Still blocking issue 51877, can we expect any progress in the near future?
This behaviour is really confusing. In addition to that your last comment is not valid Martine because current method does not pop on stack. Here is what I get with NetBeans 5.5, JDK 1.5 or 1.6 on Windows XP: 1. Line 7 breakpoint is hit. 2. Next line 8 is deleted, file saved and "Run|Apply Code Changes" is invoked. 3. F8 is pressed. Call Stack view says: Main.<obsolete>, Local Variables view is empty, no green line etc. On the other hand debugging toolbar looks like debugging session is live which proves debug node under "Processes" in Runtime view. 4. I can press F8 key say 10 times without any visual feedback until debugger session is finally finished. The code is as simple as this one class with main method: 5 public static void main(String[] args) { 6 int n = 50; 7 System.out.println("n = " + n); 8 System.out.println("Hello!"); 9 }
We can not pop from the main method. There is nothing outside, so we do pop only when you're in some nested method. I've reproduced this. It's a problem with obsolete frames. It depends on issue #58450.
Changing TM for open issues.
This would decrease the usability of "Apply Code Change" feature, which IMHO is a very important; it keeps the Debugger apart from simple logging and tracing.
alexlamsl, do you have some specific steps in mind? When changes were successfully applied, there should be no problems with stepping (besides issue #145421), the line numbers should be correct after we pop from the old method. The code is unsynchronized when the changes can not be correctly applied, but that is to be expected. Can you please provide some specific use-case?
I guess having a copy of the old source code to reference to is perhaps confusing to the other extreme... However, having some visual indication (other than seemingly malfunction of debugger stepping) that something is not right would be appreciated. I cannot think of better suggestion to put in the message than restart the application *blush*, but then a concrete advice is better than speculations (pun intended)...
*** Issue 58450 has been marked as a duplicate of this issue. ***
What do you observe as the current behavior? For me, the methods in which the changes were applied, are marked as <obsolete> in the Debugging view and the steps are "blind" - no green line is present. Therefore there should be no confusion of where the stepping is actually performed, After you go out of the obsolete method, you get the normal stepping again. Is this what happens to you as well?
Strangely enough, that's not what I observed last time I tried - I simply lost the indicator for stepping lines of code. I will try again to see what I get with another (more recent) daily build - but from your descriptions, that <obsolete> marker would seem to be good enough as a visual indication. For all I want is not to confuse the debugger user when things aren't working as expected.
Unfortunately, we are close to release and no P3s are allowed to fix, therefore we have to schedule this issue for next release.
I do not think this issue is fixable. I've tested with a simple program like: 3 public class JavaApplication { 4 5 public static void main(String[] args) { 6 doTest(100); 7 } 8 9 private static void doTest(int n) { 10 int s = 0; 11 for (int i = 0; i < n; i++) { 12 s += doTheTest(i); 13 } 14 } 15 16 private static int doTheTest(int i) { 17 return 2; 18 } 19 } Put a breakpoint at line 17 and debug. Change "s += ..." to "s -= ..." at line 12. Save and apply changes. After step, you get from doTheTest() back into doTest() method, which is obsolete now, it's named as <obsolete> in Debugging view and there is no variable/line number information in that obsolete method. This makes stepping in this method to be "blind". Step into/over works, therefore the next step into brings you into doTheTest() again. Unless you step out from the obsolete methods (doTest() in this case), or you pop the obsolete methods off the stack, stepping will be "blind", since the debugger infrastructure in JDK does not provide line number information in obsolete methods.
(In reply to Martin Entlicher from comment #22) > stepping will be "blind", since the debugger infrastructure in JDK does > not provide line number information in obsolete methods. Can somebody file a qualified bug against JDK to fix this problem?