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.
Since upgrading to NetBeans 6.8, I kept on running out of disk space in my c drive. I kept uninstalling old programs, and still I ran out of disk space very quickly again, which caused everything to stop working each time, so I had to kill NetBeans. After tracing down the problem it turns out in the .netbeans\6.8\var\log directory NetBeans is creating 100s of files, and one of the files called messages.log is about 2GBs in size (I had to kill NetBeans as this file was growing very quickly). Most of the files are copies of our source files called names like : filename.java_1.dump There are about 100 copies of each many of our source files each containing: Coupling error: class file file:/filename.java source file file:/filename.java ----- Source file content: ---------------------------------------- followed by the entire source file The messages.log file was so big that none of the text editors on my computer could open in. I quickly wrote my own one. It contains many lines starting with: INFO [org.netbeans.modules.search.BufferedCharSequence]: <init> source=[channel = sun.nio.ch.FileChannelImpl many lines starting with WARNING [com.sun.tools.javac.comp.Attr]: Attr.attribClass has a null env for class: [ and the complete contents of many of our source files many times over. Obviously it contains piles of other information, but I don't have time ot look all the way through a file that is 2GBs. As well as this NetBeans is also consuming all the CPU and amazing amounts of memory. I have compressed the messages.log file down to 120MB, but obviously this is still to big to send, and it contains our confidential source code, but at least this way I can find out extra information from it if need be. I am reverting back to using NetBeans 6.7, which also performs very poorly, but at least it doesn't consume all my disk space.
Please attach here call stack so I can see where are these logs generated. (Is there call stack in log for those INFO/WARNING messages? Are there only big messages.* files or also other big files?
The messages.log file does not appear to contain any call stacks. Only the messages.log file is extremely large, the 100s of other files are only slightly bigger than our source file, but there are 100s of them the same getting written in under a minute so they also consume a lot of disk space (they were up to a total of almost 1GB when I killed NetBeans).
I am afraid that without a reproducible test case it may take several rounds before we find out what is wrong. Regarding the dump files: -there is (should be) an exception at the end of the file. This exception may be useful for diagnostics. -what is the relation between class file and source file entries in the dump files? Are they the same file? -is there some specific/uncommon pattern used in the files for which the dump has been produced? I have found one way to produce the coupling abort, described in bug #178758 (it is however unclear if that could be related to your case). Regarding the log file: -the logging as been introduced in bug #147656 to help with diagnostics. This command line option disables it: -J-Dcom.sun.tools.javac.comp.Attr.level=1000 -is there specific/uncommon pattern used in the classes that are part of the log? How do the classes look like (e.g. do they have complex type parameters?). The "[org.netbeans.modules.search.BufferedCharSequence]:" log has been fixed as bug #178446. Thanks.
Hello, we would really appreciate if you could help us to track this problem down. If you want to use NetBeans 6.8 you can start it with --nologging - that should suppress the messages.log completelly (or use the option that Jan Lahoda described above). But in order to diagnose we actually need at least one copy of at least parts of what has been generated when it went so badly wrong for you. Thanks a lot, David
1) Here are the exceptions from 2 different dump files: ----- Trees: ------------------------------------------------------- METHOD: actionPerformed ----- Stack trace: --------------------------------------------- com.sun.tools.javac.util.CouplingAbort at org.netbeans.modules.java.source.TreeLoader.couplingError(TreeLoader.java:203) at com.sun.tools.javac.comp.MemberEnter.visitMethodDef(MemberEnter.java:673) at com.sun.tools.javadoc.JavadocMemberEnter.visitMethodDef(JavadocMemberEnter.java:65) at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:656) at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:425) at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:437) at com.sun.tools.javac.comp.MemberEnter.finishClass(MemberEnter.java:449) at com.sun.tools.javac.comp.MemberEnter.finish(MemberEnter.java:1137) at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1104) at com.sun.tools.javac.code.Symbol.complete(Symbol.java:405) at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:803) at com.sun.tools.javac.comp.Attr.visitClassDef(Attr.java:573) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:587) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:381) at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:418) at com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:1546) at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1350) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:381) at com.sun.tools.javac.comp.Attr.attribArgs(Attr.java:442) at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1313) at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1299) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:381) at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:405) at com.sun.tools.javac.comp.Attr.visitExec(Attr.java:1095) at com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1145) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:381) at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:418) at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:434) at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:790) at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:768) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:381) at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:418) at com.sun.tools.javac.comp.Attr.attribStatToTree(Attr.java:322) at com.sun.tools.javac.api.JavacTaskImpl.attributeTreeTo(JavacTaskImpl.java:766) at org.netbeans.api.java.source.TreeUtilities.reattributeTreeTo(TreeUtilities.java:509) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery.getEnvImpl(JavaCompletionProvider.java:4417) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery.getCompletionEnvironment(JavaCompletionProvider.java:4352) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery.resolveToolTip(JavaCompletionProvider.java:391) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery.run(JavaCompletionProvider.java:379) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery$Task.run(JavaCompletionProvider.java:4549) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:129) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:113) at org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:190) at org.netbeans.modules.parsing.impl.TaskProcessor.runWhenScanFinished(TaskProcessor.java:221) at org.netbeans.modules.parsing.api.ParserManager.parseWhenScanFinished(ParserManager.java:106) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery.query(JavaCompletionProvider.java:279) at org.netbeans.spi.editor.completion.support.AsyncCompletionTask.run(AsyncCompletionTask.java:218) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:602) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1084) ----- Classpath: --------------------------------------------- bootPath: C:\Program Files\Java\jdk1.6.0_17\jre\lib\resources.jar;C:\Program Files\Java\jdk1.6.0_17\jre\lib\rt.jar;C:\Program Files\Java\jdk1.6.0_17\jre\lib\sunrsasign.jar;C:\Program Files\Java\jdk1.6.0_17\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.6.0_17\jre\lib\jce.jar;C:\Program Files\Java\jdk1.6.0_17\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.6.0_17\jre\classes;C:\Program Files\Java\jdk1.6.0_17\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.6.0_17\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.6.0_17\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.6.0_17\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.6.0_17\jre\lib\ext\sunpkcs11.jar classPath: [our class path was written here] ----- Original exception --------------------------------------------- java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.<init>(String.java:215) at java.lang.StringBuffer.toString(StringBuffer.java:585) at java.io.StringWriter.toString(StringWriter.java:193) at com.sun.tools.javac.tree.JCTree.toString(JCTree.java:346) at java.lang.String.valueOf(String.java:2826) at java.lang.StringBuilder.append(StringBuilder.java:115) at com.sun.tools.javac.comp.Flow.visitVarDef(Flow.java:752) at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:712) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Flow.scanStat(Flow.java:503) at com.sun.tools.javac.comp.Flow.scanStats(Flow.java:511) at com.sun.tools.javac.comp.Flow.visitBlock(Flow.java:771) at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:768) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Flow.scanStat(Flow.java:503) at com.sun.tools.javac.comp.Flow.visitIf(Flow.java:1110) at com.sun.tools.javac.tree.JCTree$JCIf.accept(JCTree.java:1118) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Flow.scanStat(Flow.java:503) at com.sun.tools.javac.comp.Flow.scanStats(Flow.java:511) at com.sun.tools.javac.comp.Flow.visitBlock(Flow.java:771) at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:768) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Flow.scanStat(Flow.java:503) at com.sun.tools.javac.comp.Flow.visitMethodDef(Flow.java:714) at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:656) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Flow.visitClassDef(Flow.java:659) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:587) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:1348) 2) The class files and source files are the same file in each case (the even both have the java extension and the same path) 3) The only thing I can see in common with the files is that they were files that I was in the middle of editing. 4) I don't see any specific/uncommon pattern with the files in the log. There is one very large one (50,000 lines of code - NetBeans warns me every time I open this file). It makes heavy use of generics, but its class definition does not take any parameters.
Thank you very much for the logs. The first CoupligAbort is almost certainly bug #178758. I will try to look at it. The OOME relates to logging introduced due to bug #143923 - disabling logging should disable it, but something will probably not work correctly (in this case, some compilation errors may not be reported). A small standalone case that provokes the log (from com.sun.tools.javac.comp.Flow) would allow us to fix the root cause (the same applies for the log from Attr).
Small Reproducible Test Cases for this are almost impossible to make. If I have logging turned off I can't see when the problems are happening. If I have logging turned on it is killing my computer. The source files in the dumps are not small files, so guessing what part of the files is triggering these logs is near impossible. I can find out more information from the 2GB messages.log if that would be of help, and you could tell me what to search for. Maybe you guys could change your debugging logging to only include the source file name, and source line number in the messages.log (instead of the entire source file each time), and only include a filename.dump if there is not already a filename.dump with the same name [in which case it should note in the messages.log that the dump file might be different than the source file]. This should at least slow down the problem long enough that we could then isolate the root causes of these problems.
Good idea. I have changed the two logs so that they log only name, position and file (if can be found): http://hg.netbeans.org/main/nb-javac/rev/1a8aff6544ca http://hg.netbeans.org/jet-main/rev/77cd71e9799a I have also added a property that limits the number of dump files (per file for which the dump is generated) - was hardcoded to 255 before: -J-Dorg.netbeans.modules.java.source.parsing.JavacParser.maxDumps=<limit>
Integrated into 'main-golden', will be available in build *200912190200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/77cd71e9799a User: Jan Lahoda <jlahoda@netbeans.org> Log: #178736: adding a property to control how many .dump files will be created -J-Dorg.netbeans.modules.java.source.parsing.JavacParser.maxDumps, incorporating recent adjustments from nb-javac.
The logging has been limited (see the commit logs above). I think that these changes should be integrated into 6.8 patch 1 (the bug needs to be closed to allow this). I think that a new bug with specific info should be filled for the second problem (logging from Flow and Attr) - a reproducible test case will probably be needed in order to fix that. Thanks.
Verified in trunk.
The fix has been ported into the release68_fixes repository. http://hg.netbeans.org/release68_fixes/rev/dad533b7545a
V.