Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 135807 - Netbeans 6.1 hangs during code navigation
Netbeans 6.1 hangs during code navigation
Status: VERIFIED FIXED
Product: java
Classification: Unclassified
Component: Navigation
6.x
Macintosh Mac OS X
: P2 (vote)
: 6.x
Assigned To: Tomas Zezula
issues@java
61fixes3-fixed
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-26 13:30 UTC by sbtourist
Modified: 2008-09-04 13:24 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
Netbeans 6.1 thread dump during code navigation hanging (23.82 KB, text/plain)
2008-05-26 14:50 UTC, sbtourist
Details
Netbeans 6.1 thread dump during code navigation hanging (22.93 KB, text/plain)
2008-05-26 14:51 UTC, sbtourist
Details
Netbeans 6.1 thread dump during code navigation hanging (24.66 KB, text/plain)
2008-05-26 14:51 UTC, sbtourist
Details
Netbeans 6.1 thread dump during code navigation hanging (21.38 KB, text/plain)
2008-05-26 14:52 UTC, sbtourist
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sbtourist 2008-05-26 13:30:37 UTC
Hi,

as reported here: http://www.nabble.com/NetBeans-6.1-hanging-during-source-editing-navigation-td17399595.html
Netbeans 6.1 hangs for several seconds during code editing and navigation: in particular, it always hangs after opening
the code navigator, bringing my CPU to 100%.
I've experienced this problem on my MacBook with MacOSX 10.4 and JDK 1.5.
After analyzing several thread dumps (you can take a look at them into the message linked above), the problem seems to
be clearly the following thread:

"Java Source Worker Thread" prio=6 tid=0x00574770 nid=0x1aacc00 runnable [0xb42c7000..0xb42c8d10]
	at java.io.UnixFileSystem.canonicalize0(Native Method)
	at java.io.UnixFileSystem.canonicalize(UnixFileSystem.java:157)
	at java.io.File.getCanonicalPath(File.java:531)
	at java.io.File.getCanonicalFile(File.java:555)
	at org.openide.filesystems.FileUtil.normalizeFileOnMac(FileUtil.java:1365)
	at org.openide.filesystems.FileUtil.normalizeFile(FileUtil.java:1337)
	at org.netbeans.modules.java.source.parsing.FolderArchive.getFiles(FolderArchive.java:102)
	at org.netbeans.modules.java.source.parsing.CachingFileManager.list(CachingFileManager.java:116)
	at org.netbeans.modules.java.source.parsing.ProxyFileManager.list(ProxyFileManager.java:141)
	at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2182)
	at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1820)
	at com.sun.tools.javac.code.Symbol.complete(Symbol.java:401)
	at com.sun.tools.javac.code.Symbol$PackageSymbol.flags(Symbol.java:633)
	at com.sun.tools.javac.comp.Attr.checkId(Attr.java:2203)
	at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:1985)
	at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1655)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:387)
	at com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:569)
	at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:504)
	at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:420)
	at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:432)
	at com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:553)
	at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:451)
	at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:420)
	at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:942)
	at com.sun.tools.javac.code.Symbol.complete(Symbol.java:401)
	at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:784)
	at com.sun.tools.javac.comp.Enter.complete(Enter.java:609)
	at com.sun.tools.javac.comp.Enter.main(Enter.java:587)
	at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:843)
	at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:357)
	at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:303)
	at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.updateFile(RepositoryUpdater.java:2179)
	at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.access$2800(RepositoryUpdater.java:1230)
	at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker$1.run(RepositoryUpdater.java:1473)
	at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker$1.run(RepositoryUpdater.java:1272)
	at org.netbeans.modules.java.source.usages.ClassIndexManager.writeLock(ClassIndexManager.java:105)
	at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.run(RepositoryUpdater.java:1269)
	at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.run(RepositoryUpdater.java:1230)
	at org.netbeans.api.java.source.JavaSource$CompilationJob.run(JavaSource.java:1550)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
	at java.lang.Thread.run(Thread.java:613)

It's the unique (meaningful) runnable thread during the hanging period, and it uses the
org.openide.filesystems.FileUtil.normalizeFile(..) method, which should be rather resource wasteful, as reported by
javadocs:
http://bits.netbeans.org/dev/javadoc/org-openide-filesystems/org/openide/filesystems/FileUtil.html#normalizeFile(java.io.File)
Why does it call that method during code navigation?
Any ideas?
I think this bug is rather serious, because it makes core NetBeans features such as code navigation almost unusable,
that's why I've raised a P2 priority.

Thanks,
Cheers,

Sergio B.
Comment 1 Tomas Zezula 2008-05-26 14:29:35 UTC
>It's the unique (meaningful) runnable thread during the hanging period, and it uses the
>org.openide.filesystems.FileUtil.normalizeFile(..) method, which should be rather resource wasteful
The call is expensive in times of milliseconds - needs to read the inode (no seconds).
The navigator needs to call it on Mac because of case insensitive but preserving filesystem.
Both path A.java and a.java point to file containing public class A {} but the first is valid the second is an error.
On Mac (HFS) unlike other UNIX FSs you need to get the FS normalized path to distinguish these two cases.
Can you attach more thread dumps? This may happen when you have broken NFS disks or removeable media.
Comment 2 sbtourist 2008-05-26 14:49:45 UTC
Hi,

thanks for your explanation: it's clearer now.
However, I still have a question: why doesn't it happen on NB 6.0 (with same computer, same OS and same JDK)? It works
great ...

I have everything on my local hard drive, so it's not a network/removable fs problem: however, I'm attaching four thread
dumps.
Let me know.
Thanks,
Cheers,

Sergio B.
Comment 3 sbtourist 2008-05-26 14:50:58 UTC
Created attachment 61919 [details]
Netbeans 6.1 thread dump during code navigation hanging
Comment 4 sbtourist 2008-05-26 14:51:24 UTC
Created attachment 61920 [details]
Netbeans 6.1 thread dump during code navigation hanging
Comment 5 sbtourist 2008-05-26 14:51:45 UTC
Created attachment 61921 [details]
Netbeans 6.1 thread dump during code navigation hanging
Comment 6 sbtourist 2008-05-26 14:52:26 UTC
Created attachment 61922 [details]
Netbeans 6.1 thread dump during code navigation hanging
Comment 7 Tomas Zezula 2008-05-26 15:41:28 UTC
The normalization was added into NB 6.1
See issues #126392 and issue #118108

Can you list the mounted filesystems (mount)?

Comment 8 sbtourist 2008-05-26 15:45:29 UTC
Here is the output of the "mount" command:

/dev/disk0s2 on / (local, journaled)
devfs on /dev (local)
fdesc on /dev (union)
<volfs> on /.vol
automount -nsl [176] on /Network (automounted)
automount -fstab [181] on /automount/Servers (automounted)
automount -static [181] on /automount/static (automounted)
Comment 9 Tomas Zezula 2008-06-17 16:06:27 UTC
The delay is probably caused by the automounted network disk, the usage of disk is caused by the automount process.
Are you still able to reproduce it?
There is no clean solution of this problem since the app is blocked in native code in JDK which I cannot affect, but I may add an command line option 
which disables the normalization on Mac (not by default because of the issue #118108).
Comment 10 sbtourist 2008-06-17 16:14:19 UTC
It would be great if you could add such a command line option through a NetBeans 6.1 patch: I had to downgrade to 6.0,
due to this problem.
Thanks,
Cheers,

Sergio B.
Comment 11 Tomas Zezula 2008-06-17 16:20:37 UTC
OK.
I will add it into a dev build (NB 6.5) and tried to propagate it into the NB 6.1 in some patch set if possible.
Comment 12 Tomas Zezula 2008-06-18 07:49:48 UTC
Fixed in: 8a018a522fad
The command line option is: -J-DFolderArchive.noNormalize=true

Comment 13 Quality Engineering 2008-06-19 04:30:58 UTC
Integrated into 'main-golden', available in NB_Trunk_Production #268 build
Changeset: http://hg.netbeans.org/main/rev/8a018a522fad
User: Tomas Zezula <tzezula@netbeans.org>
Log: #135807:Netbeans 6.1 hangs during code navigation
Comment 14 rbalada 2008-08-04 15:53:47 UTC
Please note that NetBeans 6.1 Patch3 cut-off is going to happen on close of
business August 5th. If you would like to have bugfix for this issue as part of
NetBeans 6.1 Patch3, then this issue must have information about bugfix' trunk
changeset and it's status must be "VERIFIED".
Comment 15 Jiri Prox 2008-08-05 09:35:34 UTC
verified
Comment 16 rbalada 2008-08-05 09:45:38 UTC
I've transplanted the changeset http://hg.netbeans.org/main/rev/8a018a522fad into release61_fixes repository as
http://hg.netbeans.org/release61_fixes/rev/51f58cb231a1


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo