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.
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.
>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.
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.
Created attachment 61919 [details] Netbeans 6.1 thread dump during code navigation hanging
Created attachment 61920 [details] Netbeans 6.1 thread dump during code navigation hanging
Created attachment 61921 [details] Netbeans 6.1 thread dump during code navigation hanging
Created attachment 61922 [details] Netbeans 6.1 thread dump during code navigation hanging
The normalization was added into NB 6.1 See issues #126392 and issue #118108 Can you list the mounted filesystems (mount)?
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)
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).
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.
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.
Fixed in: 8a018a522fad The command line option is: -J-DFolderArchive.noNormalize=true
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
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".
verified
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