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: | Background scanning of projects never ends and Netbeans is not checking for Java errors. | ||
---|---|---|---|
Product: | java | Reporter: | achirizzi |
Component: | Source | Assignee: | Tomas Zezula <tzezula> |
Status: | NEW --- | ||
Severity: | normal | CC: | achirizzi, dkenny, nigjo_iqn |
Priority: | P3 | ||
Version: | 8.0.2 | ||
Hardware: | PC | ||
OS: | Windows 7 x64 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
IDE log
NB Thread Dump (via kill -QUIT pid) .npss file attached from NetBeans Second NB Thread Dump (via kill -QUIT pid) Screenshot of NetBeans while trying to close it (for it's not working) |
Description
achirizzi
2015-05-28 10:43:59 UTC
Created attachment 153919 [details]
IDE log
Seems as a deadlock in the IDE. Please can you attach the IDE self sampler file or several successive thread dumps as described here: http://wiki.netbeans.org/GenerateThreadDump http://wiki.netbeans.org/FitnessViaPartnership Thanks! I will try to attach what requested if the problem shows again. I think the main problem was that I was executing some tests in a temporary folder of the project open in Netbeans. Since the tests were creating a lot of files in that folder, I think NB must have incurred in some bug trying to stay up to date with all the files in the project (which were not java files or anything important to NB, just temporary files with random names). Does this help? The NetBeans should be guarded to prevent this. There are two kinds of barriers: 1st) The scan cares just about the project source roots (the source path) it does not care about any other folders. If the tmp folder was under the project but not in sources (test sources) it should be OK. 2nd) During the test run (compilation) the changes are ignored and grouped together into one big event which is processed either after the run or after timeout. But if you are able to reproduce it the self profile file will be helpful. Thanks a lot! Actually... now that I recall correctly, I was working on some java classes to test git and the JGit library. So, even though I was only producing random text files (with the "lorem ipsum" texts) in some temporary directory, I was anyway doing a lot of "git add", "git submit" and "git push" under a directory contained by the NB project. So maybe this can knock out NB with the git plug-in. Anyway if it happens again (i.e. if I am going to run those long tests and also use NB) I will attach what you've requested. Thanks -Antonio Created attachment 156455 [details] NB Thread Dump (via kill -QUIT pid) I am attaching the thread dump for NB. I can now easily reproduce the problem of a never-ending "Background scanning of projects..." I simply renamed (refactor/rename) a class, in a complex project, thought. The project is the latest gerrit source code. (git clone https://gerrit.googlesource.com/gerrit) There is no easy way to set up this project in NB, because the google guys only provide a way to import the project in Eclipse, and, by the way, there is another bunch of bugs related to importing the project from Eclipse to NB. Now, supposing you can import the project (I can send you a tar of my sources, since anyway we have to make them available) you can try yourself to rename the class. The class is a new class I added in the package gom.google.gerrit.common. File name: ReplicatedIndexEventManager.java The class has some code inside (just about 50 lines). Fact: I rename the class because I think the name is not appropriate and after a few seconds the scan starts and lasts forever, making all the things very slow. I did this 2 times today, that's why I discovered how to reproduce the problem. Please let me know if you need more data. Thanks, -Antonio Reopening the bug after attaching some pertinent data Created attachment 156456 [details]
.npss file attached from NetBeans
.npss file
Attaching profile as per FitnessViaPartnership I am editing a java class, I change file to another class, and the Members window takes forever to appear, as also all the error checking features in the new java class. Created attachment 156465 [details]
Second NB Thread Dump (via kill -QUIT pid)
Attaching a second thread dump.
At the moment of the thread dump Netbeans looks almost frozen from the point of view of error checking, class members showing, code completion, and so on.
But the "fix imports" works.
This time I have not renamed any class, just edited some files since yesterday, after restarting NB.
Regards
-Antonio
Created attachment 156466 [details]
Screenshot of NetBeans while trying to close it (for it's not working)
Following the NB thread dump I am adding a screenshot of NB to show what it is doing. A "Checking for external changes" task is running but it's suspended (?).
I am closing the IDE cause I can't work anymore in this state.
If I click on "exit ide" the UI will disappear, but the java process will still be running.
The scan (and everything else) is blocked by: org.netbeans.modules.j2ee.metadata.model.api.support.annotation.AnnotationModelHelper I will find what the AnnotationModelHelper is doing and reassign to j2ee/<?>. According to the self sampler there are 234 resolution of the ElementHandle in the J2EE AnnotationModelHelper but the resolution (IO operation) is very slow. This action is executes as a task which suspends the scan, the scan waits until it finishes. The resolution of a single ElementHandle takes ~ 0.6s which is strange. Even if the scan will not wait for the J2EE AnnotationModelHelper it will block other operations like editor, etc. To reporter: What is the type of the project? Ant, maven? How many items are on classpath? How many source roots the project has? Thanks The project is gerrit. As I said in my previous comment: > The project is the latest gerrit source code. (git clone > https://gerrit.googlesource.com/gerrit) > There is no easy way to set up this project in NB, because the google guys only > provide a way to import the project in Eclipse, and, by the way, there is another > bunch of bugs related to importing the project from Eclipse to NB. What I did was to download the source code from the gerrit repo, follow the instructions to build the code and get the Eclipse project. Then import the eclipse project into NB with some effort. It's not easy and NB has a lot of bugs in this case. This has been working for almost a year, but 2 months ago I started seeing the problem I am describing here. Thanks! I will try. I see this behavior in simple (in file) Python projects, too. >I see this behavior in simple (in file) Python projects, too. This happens when the language parser (in this case Python) hangs. Caused either by a bug in the parser or wrong parser integration. Please fill an issue on NetBeans Python support or attach a thread dump (http://wiki.netbeans.org/GenerateThreadDump) and I will do it. I'm experiencing the same issue in Java right now - code highlights are going crazy, and a file is marked as in error but no lines are in error. Whenever I make an update to a file in the project, NB seems to hang on 'loading tasks', but no changes to the error highlight occurs. p.s. - I can confirm by forcing an error into a different file that the new file does not show a new error. And, removing all errors from the file it thinks has an error in it does not remove the existing error marker. hai, Background scanning of projects never termined. Help. |