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.
Summary: | [50cat] [tools] Single step, continue, and step into are not working when debugging modules, break points not catching correctly | ||
---|---|---|---|
Product: | debugger | Reporter: | _ wadechandler <wadechandler> |
Component: | Java | Assignee: | issues@debugger <issues> |
Status: | CLOSED FIXED | ||
Severity: | blocker | ||
Priority: | P3 | ||
Version: | 5.x | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
netbeans messages.log file from the IDE
netbeans messages.log from the running platform. |
Description
_ wadechandler
2005-12-14 02:57:38 UTC
*** Issue 70374 has been marked as a duplicate of this issue. *** *** Issue 70373 has been marked as a duplicate of this issue. *** Created attachment 27810 [details]
netbeans messages.log file from the IDE
Created attachment 27811 [details]
netbeans messages.log from the running platform.
I have attached my log files. I'll hold off attaching anything else for now. It seems the log file from the IDE has some pretty good info. I built the IDE from a CVS checkout of "standard". I assumed the debugger should be working. If I need to get another version and try it please let me know. I suppose you have opened you module via File -> Open Project. Please, have a look you have your sources in the Sources view (when debugging -- menu Window -> Debugging -> Sources -- set Use for debugging). Hmm. Apparently I didn't have that checked. I thought I did as I was actually getting to break points. In previous versions I'm pretty sure 4.1. When you didn't have this checked you didn't get stopped on any break points, so you knew exactly what was wrong if you new about the debugger sources. It seems like this shouldn't stop at all if the sources check box for this source isn't checked. Yes, current behavior is to stop even when not checked in sources view. This is because of debugging of JDK. On the other hand, it is possible we will change the whole concept of sources view in the future. I was told in the netcat5.0 mailing list to reopen because of the exceptions and hanging of the IDE. From Net Cat: "If you are still experiencing problems after proper setup of sources, reopen the issue. When sources are not set for debugging, the breakpoints are reached and breaks execution. But invoking step operation behaves same as continue. No exceptions should be thrown, no hangup of debugger. If this does not work, it is a P1 bug. But I have no prolems with it. Lubo" "Lubomir Cincura" <Lubomir.Cincura@Sun.COM> What happens is that you press step over or into and it tries to behave like a normal continue, but it hangs and acts very slow, and does not act like continue. Both the debugged and the debugger act strangely. I imagine it's from the thrown exceptions you can see in the IDE log file. I would imagine it would just run on, but it doesn't. So, if it still stops on break points and acts just like continue: 1) I would expect it to stop on the break points <- It does this 2) I would expect it to stop on the next break point when I hit continue, step over, or step into <- It does not do this. Explanation of 2: Say I have lines File f = new File("blah blah");: break point 1 if(!f.exists()){ //do something and make sure it does } //work with file [code]: break point 2 If the debugger is not currently stopped in the file with this code and these are the only two break points in the file. It will stop on break point 1. When I press continue, step over, or step into according to what I understand the correct behavior to be it should continue and stop on break point 2 and act just like any other debugging session other than everything acts like continue. 1) Indeterminate hanging occurs. (the time is not static and sometimes it doesn't hang too long and other times it will hang for a long time) 2) It doesn't stop on any other break points other than the one it stopped on when it wasn't debugging the file. i.e. the file was not being debugged yet, a break point is caught, now this file is being debugged, no other break points in this file will catch, if another file has break points that will be reached these will catch (sometimes, but never the same file), after the file has changed break points in a previous file may be reached again 3) You can not examine the variables or anything like you could if it were behaving like a normal debug session except all the buttons act like continue 4) Sometimes the buttons [continue, step over, and step into] will be visible like the debugger has stopped yet no line is highlighted and the screen locks up a bit. It's like it's stopping on break points, yet it's not allowing you to see the variables nor is it showing which break point it is stopped on. If anything isn't clear here please ask me to elaborate more, and I'll be happy to. If you need any other log files or anything. All I did here was: 1) New Project->"Module Project" 2) Started writing code 3) decided to debug some of it without remembering to check the sources for the project Personal Note/Opinion: I suppose I would have expected the project sources to automatically be checked to debug since I have my project set as the main project. At least for the first time it has been debugged. Apparently the checked sources for debug are persisted between IDE runs, so it seems like this would be possible. We had to reduce the number of classes (performance reasons), so these exceptions are as designed (should not occur with a fresh user dir). I took the last comment and deleted my dev user directory from my %userprofile%\.netbeans directory and the errors went away. However, the debugger does not act anything like a normal debugger...no break points are caught in source code that is not checked to be debugged. This is how I would have expected it to behave though. So, instead of the debugger working the same and having step over and into work like continue Ijust don't get any debugger activity for sources without a check box. It behaves as should for sources with the check box. Is this the correct behaviour? I'm a little confused by some other comments. I was expecting...based on the other comments....for the break points to catch and to find that step over and into work like continue for sources which are "not" checked to be debugged in the debugger sources view. However, it does behave as I would have expected it to. Well, there is no exact definition of the behavior regarding breakpoints when the sources are un-checked AFAIK. But the current behavior for us is that the breakpoints are hit, but step works like continue. But it's true, that sometimes the debugger behaves strange - it occasionally stops without the green line somewhere in the unchecked sources and sometimes it seems like it miss some breakpoints. However, this does not seem to be consistent and it's seems to be reproducible only with large applications (not HelloWorld-like applications). OTOH when you do not put breakpoints into the unchecked sources, the calls to appropriate method are skipped correctly. However, if sources are properly checked on, I have no problems. There is already enhancement #63879 submitted, which concerns the Sources Window and the not-much-intuitive design. We'll find some solution of it for 5.1. That should basically resolve the problem. I agree that there is some problem with how debugger behaves when the sources are not checked on. Since this is most probably an unwanted situation anyway, I'm downgrading this to P3 (the correct use-case with enabled sources works well) and we'll be solving this into 5.1. *** Issue 85086 has been marked as a duplicate of this issue. *** Changing TM for open issues. in NB 6.x breakpoints in sources not enabled for debugging do not work. Therefore they are consistent with steps. We plan to redesign the sources management into NB 7.0, the behavior might be polished. I hope that this can be fixed now - when sources are not enabled for debugging, breakpoints are marked as invalid (with a message printed into debugger console) and steps just skip such sources. Therefore it should behave consistently now. Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier. |