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.

Bug 202195 - Netbeans hangs at around 96% scanning a project.
Summary: Netbeans hangs at around 96% scanning a project.
Status: RESOLVED DUPLICATE of bug 207214
Alias: None
Product: editor
Classification: Unclassified
Component: Parsing & Indexing (show other bugs)
Version: 7.0.1
Hardware: Sun Solaris
: P3 normal (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-15 16:29 UTC by davetong
Modified: 2012-01-26 16:05 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
contents of var/log and a series of 11 jstack dumps as tar.gz file (1.09 MB, application/octet-stream)
2011-09-15 16:30 UTC, davetong
Details
More stack traces (238.00 KB, application/x-tar)
2011-09-16 16:26 UTC, davetong
Details

Note You need to log in before you can comment on or make changes to this bug.
Description davetong 2011-09-15 16:29:28 UTC
When reading in a paticularly large and complex project, scanning hangs at around 96%. Some of the UI works such as loading and editing, but other parts such as searching, jumping to code, formatting etc do not. Scanning never completes even if left overnight.
On exiting the UI hangs due to the AWT event thread being blocked.

Product Version: NetBeans IDE 7.0.1 (Build 201107282000)
Java: 1.6.0_15; Java HotSpot(TM) Client VM 14.1-b02
System: SunOS version 5.11 running on x86; ISO646-US; en (nb)
Userdir: /home/qqqq/.netbeans/7.0

Project uses Mercurial. Workspace is local. 
Access can be made available to Oracle employees.

I have attached the contents of var/log as well as a series of stack traces taken before the hang, while hung, and after attempting to exit.
Comment 1 davetong 2011-09-15 16:30:36 UTC
Created attachment 110795 [details]
contents of var/log and a series of 11 jstack dumps as tar.gz file
Comment 2 Tomas Zezula 2011-09-16 07:22:50 UTC
Here is what I've found from thread dumps:
The first thread dump is initialization of IDE queries - seems OK.
The second is collecting of projects classpaths and topological sort of dependencies - OK.
The dump 3-8 are JavaCustomIndexer (indexing java sources) and BinaryIndexer(indexing jar files) and SpringIndexer (some web indexer looking for some Spring metadata, I don't know much about this) - seems also OK.
The dump 9-11 are strange. It's adding of recursive listener which should be fast, may be a bug in NB file system API.

Can you try to start netbeans with -J-Dnetbeans.indexing.recursiveListeners=false ?
Thanks
Comment 3 davetong 2011-09-16 16:26:17 UTC
Created attachment 110822 [details]
More stack traces

netbeans run with the flag -J-Dnetbeans.indexing.recursiveListeners=false
Comment 4 Tomas Zezula 2011-09-16 18:33:02 UTC
WIth the option -J-Dnetbeans.indexing.recursiveListeners=false you still have the same problem, right?
Comment 5 davetong 2011-09-16 18:39:57 UTC
Hmm. it deleted my comment for some reason.

I ran with -J-Dnetbeans.indexing.recursiveListeners=false and at first it seemed to stop at 96% again. I took some jstack traces. 
Then after a few minutes it jumped to 100% but the job bid not report itself as done. I took some more jstack dumps and waited a few more minutes. Then I decided to quit and restart because I'd forgotten to set -J-Dorg.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.level=FINE

When I clicked the X it quit straight away; it did not hang in the AWT thread.
When I restarted NetBeans with both flags the scanning ran to completion without pausing at 96% 

Now everything seems to be working perfectly. I attached the thread dumps anyway in case they are helpful but setting recursiveListeners=false seems to have done the trick, thanks.
Comment 6 Tomas Zezula 2011-09-16 19:03:24 UTC
It seems as a bug in recursive listening in the NB file system library.
I will download the project (internally) and try to reproduce it.
Thanks very much for your help!
Comment 7 Tomas Zezula 2012-01-26 16:05:42 UTC

*** This bug has been marked as a duplicate of bug 207214 ***