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.
When starting a debug session the debugger attempts to recreate breakpoints even on resources that no loger exist. This means that the startup time for the debugger will increase over time. It also causes some kvm's to return JDWP errors - this is likely an implementation problem in the vm but could be avoided by fixing this issue. This problem can be reproduced by simply creating a simple midlet, setting a breakpoint in it's startApp() method and then removing the Midlet file. You will notice that the org-netbeans-modules-debugger-Settings.properties file still contains the breakpoint and the next time the debugger is started class prepare event requests are sent for all breakpoint locations even the non-existing ones. Another side effect of this issue is that removing a java file with a breakpoint set and then creating a file with the same name results in the breakpoint magically reappearing. This issue can also be reproduced by setting a breakpoint and then renaming the java file via refactoring. The suggested fix would be to at least check if the resource and location of the breakpoint exist before sending a class prepare event request. Immediate fix for this problem is to remove the config/Services/org-netbeans-modules-debugger-Settings.properties file from the .netbeans directory. This will however remove all the breakpoints from the ide.
This should be treated together with issue #63595.
This is sort of similar to issue #55663. We need to have some listener which will delete breakpoints from removed classes.
does fix of 54449 do anything for this issue?
Yes. Well, it's in fact issue #83188, which was necessary for this. We need to know the URL of the breakpoint. After issue #83188 is fixed, we have URL also for JSP breakpoints (which provided a class filter as the URL in the past).
Fixed in trunk, breakpoints whose URL can not be resolved to a FileObject are ignored: /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/BreakpointsReader.java,v <-- BreakpointsReader.java new revision: 1.6; previous revision: 1.5 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/PersistenceManager.java,v <-- PersistenceManager.java new revision: 1.5; previous revision: 1.4 /cvs/debuggerjpda/api/src/org/netbeans/api/debugger/jpda/LineBreakpoint.java,v <-- LineBreakpoint.java new revision: 1.17; previous revision: 1.16 /cvs/ide/golden/deps.txt,v <-- deps.txt new revision: 1.307; previous revision: 1.306 /cvs/debuggerjpda/api/nbproject/project.xml,v <-- project.xml new revision: 1.11; previous revision: 1.10
plz. consider the following situation: 1) user creates Hello.java 2) sets a line breakpoint 3) deletes Hello.java 4) creates (at some later time) Hello.java -- will at this point the breakpoint still get hit when debugging Hello.java? if so, then I'd like to keep this issue open because the delivered fix would only be partial, the full fix removes breakpoints along with the resources
It depends on what exactly the user does. Where does the user delete the file? In the IDE or externally? Does the user restart the IDE in between? So, to summary what this change is about: Each line breakpoint listens on it's FileObject. Therefore when that FileObject is deleted (delete of the file inside of the IDE), the breakpoint is removed completely. When the file is renamed, the breakpoint is moved to the new file. When the file is deleted externally during the IDE is up and running and the IDE gains focus afterwards, the breakpoint is also removed. When the file is deleted externally while the IDE is closed, on subsequent start the breakpoint is ignored (not provided by the deserialization system up to the debugger). That means that as soon as the breakpoints are saved again, the breakpoint is deleted permanently. So the answer to your question is likely no (it's yes only when the user creates the project, set the breakpoint, close the IDE, delete the file, start the IDE, re-creates the file (and does nothing with breakpoints at all), close the IDE, start the IDE, then the breakpoint comes back). IMHO this solves the problem.
thnx for the detailed explanation, it's about as good of a fix as i could have asked for :)
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.