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.
Not able to submit breakpoint I am developing an ant project web application and another maven web application. In both of them I find this type of error after saving Java files with COS: Not able to submit breakpoint LineBreakpoint WicketApplication.java : 63, reason: No executable location available at line 40 in class com.mycompany.WicketApplication. Invalid LineBreakpoint WicketApplication.java : 63 So I think I wait until the app is deployed when I run it but the error does not go away. Sometimes it works other times it doesn't. It is been like this ever since I started using NetBeans with web apps. In the course of this, I see the debugger breaks on lines where no breakpoints exists. These errors seem to go away when I re-start NetBeans. Just a few minutes ago I got additional errors that I reported with the exception reporter: 652259 and 651782. I hope these error reports are a good starting point. Perhaps in the future I will be able to make a testcase, but I can't promise because this has always been difficult to do.
The additional error is submitted as issue #225350 and will be treated separately. It's not severe, it just happens when tooltip is to be shown while the application is running (not suspended). It does not have a relation to this breakpoints problem. I did not reproduce the breakpoint issue you're describing. Do you know if this happens in the Maven or Ant project? I've only found, that sometimes, after save of local modifications, if a breakpoint is moved as a result of these modifications, it's moved to a lower line number that originally submitted. But it stays valid and is hit. Maybe when the change is more complex, it breaks. I guess that re-submitting the breakpoint should be an easy workaround, is it?
Thanks. It happened in an ant project. I will see what I can do to reproduce it. This may take some time.
Created attachment 130673 [details] Screen capture of source file This is a small source file with 170 lines. I ran the web project on GlassFish the Run option in the project window. This should compile everything and the breakpoint should be valid. So I thought I fix it by doing what you said - toggle the breakpoint, but if I toggle the breakpoint then the message re-appears. I would have tried this before of course, but this time I paid more attention. There are mulltiple occurrences of this error in the file, and this time I know there were not any complex changes at all. Please keep sharpening my attention to the things that I should watch out for. Perhaps you have some logging flags for me to set?
Comment on attachment 130673 [details] Screen capture of source file I know that this code is exeuted on the server.
I re-run the application after source file changes (add some comments at the top). The IDE re-deploys the app to GlassFish. Then I toggle the same breakpoint at the last method in the file and it still doesn't fix itself.
Created attachment 130677 [details] Thread dump during IDE shutdown The attached thread dump was taken during IDE shutdown that took about 20 minutes on my slow computer. However I don't feel so bad about my computer anymore after I discovered that it lists 141 threads in total, with 15 "JPDA Debugger" threads.
I get it with a simple change of adding a single line of comment above a method. I have tried but I cannot create a test case for this using a trivial web app. I don't believe it's possible because in that case many people would have this issue. The only solution is to re-start the IDE.
Created attachment 130700 [details] Thread dump The IDE is in the same state again. Added a few lines of Javadoc at the top which has shifted code down a few lines, perhaps uncommented and re-commented out a line of source code. I tried clean, build, undeploy, deploy, re-open source file, new debugger session. Nothing helps. Will need to re-start the IDE. I don't have an idea whether the thread dump has any relevance. There is no exception in the log - just the message that the breakpoint is invalid.
The first thread dump has really a lot of threads. But most of the 15 "JPDA Debugger" threads just wait idle. Only 3 of them are refreshing source roots and are waiting for disk access. We should improve this by scheduling this to one thread only. I've submitted issue #225418 for this. This is a performance problem that should not affect functionality. Regarding to the invalid breakpoints, it looks like the breakpoint might not be updated at all after deploy of the modified project. Do you use ANT project generated by NetBeans IDE, or did you write or modified the project yourself? There is a task called "nbjpdaappreloaded" which updates the breakpoint lines after deployment. It's possible to check whether this task was called or not. The default ANT script has "-do-update-breakpoints", which contains the "nbjpdaappreloaded" and which is called during deploy. If you set "Verbose" verbosity level in Tools -> Options -> Java -> Ant and do Deploy (if you have compile-on-save, you have also deploy-on-save I guess, so deploy is called automatically after save), you should see something like this in Output: -run-deploy-am: -post-nbmodule-run-deploy: -post-run-deploy: -do-update-breakpoints: run-deploy: It's possible to verify the breakpoint updates also via logging. When you start NetBeans with -J-Dorg.netbeans.modules.debugger.jpda.ant.level=400 option (can be put into netbeans.conf), you should see logging output like this in messages.log file: This is printed when you start debug a project: FINE [org.netbeans.modules.debugger.jpda.ant]: JPDAConnect.execute ().synchronized: host = localhost port = 9009 transport = dt_socket FINE [org.netbeans.modules.debugger.jpda.ant]: JPDAConnect.execute ().synchronized end: success FINE [org.netbeans.modules.debugger.jpda.ant]: JPDAConnect.execute () end: success And this is printed when breakpoints are updated: FINE [org.netbeans.modules.debugger.jpda.ant]: JPDAAppReloaded.execute() FINE [org.netbeans.modules.debugger.jpda.ant]: Breakpoints fixed. Can you please try that? Also, can you please try to switch off both compile-on-save and deploy-on-save and check whether breakpoints become broken after source code changes followed by manual deploy via project Deploy action? Thank you.
Created attachment 130746 [details] Log files in zip file I added config as advised. The attached file contains console output as separate files. It was very easy to reproduce. Standard ant project with just a few lines in extension points. I don't think these make a difference because I have seen this in Maven, too. Deploy on save is off. IMHO DOS would complicate things too much in my case - I would not be able to figure out what the status is while I work. - Started the server in debug mode - set some breakpoints on a file that was already deployed on GlassFish. The file had not been changed for days at least - connected the debugger - Run the project. Here is a difficulty someteimes where the and script has null ${client.url}. Sii bug 215793. I then go to the server and select "Open in Browser". I never thought that this an issue because it happens last and I know what to do - all breakpoints are set correctly and I can debug the java file - Make simple changes to the file at the top - add one ot two lines of code and some comments, copy some code at the bottom and set breakpoints on it. - For the new code at the bottom, I get errors "Not able to submit breakpoint LineBreakpoint". I think this is ok because the file is not yet deployed but I may be wrong because COS is on. - Execute the run command, hoping the errors get fixed. - The application gets deployed, I can execute it ok, but I cannot fix the breakpoints. At this stage I would have to re-start the IDE because I cannot recover in the session. I did everything very very slowly as to not introduce unnecessary racing conditions. One step at the time, with much time in between steps.
Are you waiting for something? Is there anything I can do to help? I can still reproduce this. The debugger is useless for me. I must re-start the IDE every time I need to make java code changes.
Created attachment 131636 [details] test case in zip file I can reproduce two different types of errors with this test case: 1) a line breakpoint is shifted on to an @Override annotation 2) a line breakpoint is shifted on to a method declaration How to reproduce: - Start GlassFish in debug mode - attach the debugger - open the attached project - in StatelessSessionBean, set line breakpoints on the first statement of each method - in the projects window, select the project and run it - resume - in StatelessSessionBean, add two comment lines below line 22 - save StatelessSessionBean - in the projects window, select the project and run i
Created attachment 131637 [details] Screen dump of broken breakpoints
This test case is not fully equivlent because the breakpoints can be fixed quite easily. In my original project, I have to re-start NetBeans to fix them.
*** Bug 176797 has been marked as a duplicate of this bug. ***
*** Bug 184933 has been marked as a duplicate of this bug. ***
Thanks for the test project and description of the use-case. I've reproduced the bug. I've always started debugging by "Debug" on the project, not by extra attaching to the server and then running the project. This way (via attach and run) we do not catch the deploy and therefore debugger does not count with the updated binaries. This is why all breakpoints are invalid. I'll think about what can we do with it... we'd have to associate the attached debugger to the server's port with the deployment of the project to that server. When I've tested using "Debug" project instead of attach and run, I still got some invalid breakpoints (we should fix this as well), though it was easy to re-set them. When the debugger is attached, you need to finish the debugger session and attach debugger again to be able to repair breakpoints. Restart of the IDE should not be necessary.
I can't confirm that finishing the debugger session and re-attaching the debugger fixes the problem. I need a server re-start. Because of this, perhaps even with the fix that you have in mind, the problems I am seeing might not be entirely solved based on this test case. We don't have a bug yet with a title "Broken breakpoints cannot be fixed with new debugger session" But as I wrote before, the test case does not show this problem, and I haven't be able to make a test case that shows this in the same way as my application does. This reminds me of another scenario a year back with bug 206829 where the debugger had the same behavior but my testcase was less fatal than my application. The bug was fixed for the test case but here we are again in a similar situation. Later I reported bug 212735. When can you apply the fix so I can test my application with it?
*** Bug 227079 has been marked as a duplicate of this bug. ***
When would I be able to test any new developments? This my remaining top priority issue (with GlassFish / Java EE use) after 2 memory leaks which are now fixed / being addressed.
The impact of this is actually higher when line numbers are not changed. Then the debugger APPARENTLY functions as expected. But because code changes are not applied, the code executed on the server is actually different from what is seen in the editor. The debugger then becomes a stealth confuser.
Sorry, I was dealing with a combination of unrelated effects
Fixed by changeset: 262673:a8fadbbf3e06 http://hg.netbeans.org/core-main/rev/a8fadbbf3e06 When the project is run after a change in the code, new classes with changed code are created on the server. Just before debugger is notified about the reloaded classes (which triggers breakpoints update), we get class prepared event from the server VM. If a valid location does not exist on the breakpoint line, we try to repair the breakpoint by moving it to the nearest valid location in the given AST. This may move the breakpoint to a location, that is invalid after the breakpoint is updated. We therefore try to repair breakpoints only for the first loaded class, or for class instances that have the breakpoint submitted already. This fixes the problem for me.