Bug 57457 - [41cat] Debugger steps strange after "Apply Code Changes"
[41cat] Debugger steps strange after "Apply Code Changes"
Status: REOPENED
Product: debugger
Classification: Unclassified
Component: Java
4.x
Other Linux
: P3 with 6 votes (vote)
: 7.0
Assigned To: Martin Entlicher
issues@debugger
:
: 58450 58980 66254 67579 (view as bug list)
Depends on: 58450
Blocks: 51877
  Show dependency treegraph
 
Reported: 2005-04-04 22:58 UTC by johnzoet
Modified: 2014-07-11 01:01 UTC (History)
2 users (show)

See Also:
Issue Type: TASK
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description johnzoet 2005-04-04 22:58:23 UTC
[ 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.
Comment 1 Roman Ondruska 2005-04-12 09:38:07 UTC
Is this reproducible? Can you send your test-case?
Comment 2 johnzoet 2005-04-12 10:25:51 UTC
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. 
Comment 3 Roman Ondruska 2005-04-15 15:14:34 UTC
Please, send the test-case & mainly steps to reproduce. Thanks a lot!
Comment 4 johnzoet 2005-04-20 01:34:22 UTC
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. 
 
Comment 5 Milan Kubec 2005-04-24 18:27:35 UTC
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.
Comment 6 johnzoet 2005-04-27 01:10:06 UTC
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. 
 
 
Comment 7 Martin Entlicher 2005-05-05 13:38:58 UTC
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.
Comment 8 Martin Entlicher 2005-08-20 10:07:23 UTC
*** Issue 58980 has been marked as a duplicate of this issue. ***
Comment 9 Roman Ondruska 2005-10-07 15:42:27 UTC
*** Issue 66254 has been marked as a duplicate of this issue. ***
Comment 10 Roman Ondruska 2005-10-26 15:51:11 UTC
*** Issue 67579 has been marked as a duplicate of this issue. ***
Comment 11 Libor Kotouc 2006-07-31 17:27:34 UTC
Still blocking issue 51877, can we expect any progress in the near future?
Comment 12 Jiri Kovalsky 2006-08-15 15:20:22 UTC
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    }
Comment 13 Martin Entlicher 2007-01-08 10:54:59 UTC
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.
Comment 14 Peter Pis 2008-04-10 22:54:20 UTC
Changing TM for open issues.
Comment 15 _ alexlamsl 2008-09-19 13:12:05 UTC
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.
Comment 16 Martin Entlicher 2008-09-25 15:23:48 UTC
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?
Comment 17 _ alexlamsl 2008-09-26 23:55:03 UTC
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)...
Comment 18 Martin Entlicher 2008-10-06 12:16:58 UTC
*** Issue 58450 has been marked as a duplicate of this issue. ***
Comment 19 Martin Entlicher 2008-10-06 12:44:29 UTC
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?
Comment 20 _ alexlamsl 2008-10-06 23:33:31 UTC
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.
Comment 21 Peter Pis 2008-10-08 14:04:36 UTC
Unfortunately, we are close to release and no P3s are allowed to fix, therefore we have to schedule this issue for next
release.
Comment 22 Martin Entlicher 2014-07-08 14:20:22 UTC
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.
Comment 23 ulfzibis 2014-07-11 01:01:08 UTC
(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?


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo