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.
This issue was reported manually by thurka. It already has 1 duplicates Build: NetBeans IDE 7.4 (Build 201310111528) VM: Java HotSpot(TM) 64-Bit Server VM, 24.51-b03, Java(TM) SE Runtime Environment, 1.7.0_51-b13 OS: Linux User Comments: GUEST: ?? ???? Stacktrace: java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.concurrent.locks.ReentrantLock$Sync.newCondition(ReentrantLock.java:172) at java.util.concurrent.locks.ReentrantLock.newCondition(ReentrantLock.java:503) at javax.swing.TimerQueue.run(TimerQueue.java:192) at java.lang.Thread.run(Thread.java:744)
Created attachment 147415 [details] stacktrace
Retained size of 37 instances of org.netbeans.modules.css.lib.nbparser.CssParser is 529,406,600 bytes, which is 61% of a whole heap size.
*** Bug 244807 has been marked as a duplicate of this bug. ***
Two problems here: 1) o.n.m.css.refactoring.api.EntryHandle holds an implementation (CssFileModel$LazyEntry) of o.n.m.css.refactoring.api.Entry which holds its outer class org.netbeans.modules.css.indexing.CssFileModel which holds CssParserResult. I reckon this is not a severe problem as the EntryHandle-s are used just within the refactoring support. I do not assume the will be too many of these held via the refactoring UI(s). 2) CssRuleStructureItem is not a true handle but directly keeps reference to CssNodeElement which then indirectly holds CssParserResult and all related objects. This seems to be the sore point and very likely the cause of all the OOMs as the navigator UI can hold many such objects from various generations of the parser results. Each such object then keeps its parser result and all related stuff.
*** Bug 239336 has been marked as a duplicate of this bug. ***
*** Bug 243373 has been marked as a duplicate of this bug. ***
*** Bug 242379 has been marked as a duplicate of this bug. ***
*** Bug 236915 has been marked as a duplicate of this bug. ***
*** Bug 238176 has been marked as a duplicate of this bug. ***
issue #1 fixed changeset: 276082:0b9cf2f75d41 summary: #244697 - CssFileModel$LazyEntry is a static inner class so it doesn't hold the CssFileModel itself
As for issue #2 (CssNodeElement) -- the evaluation was not correct. The CssNodeElement is correct, it holds just the file and pair of offsets.
report 720692 - what looks very wrong is that the ClassMemberPanelUI$MyBeanTreeView (the navigator) holds 262144 items (VisualizerNode) which then holds the ElementScanningTask$RootStructureItem which holds all the css StructureItems. This seems to be a bug in the CLS's navigator implementation.
changeset: 276111:6e09b3a36a70 summary: #244697 - fixing bug: TopLevelStructureItem$Rules keeps reference to FeatureContext which then does hold the CssParserResult
As for the ClassMemberPanelUI$MyBeanTreeView memory leak, I've filled a new issue against CSL: https://netbeans.org/bugzilla/show_bug.cgi?id=245980
*** Bug 240946 has been marked as a duplicate of this bug. ***
*** Bug 240158 has been marked as a duplicate of this bug. ***
Integrated into 'main-silver', will be available in build *201407260001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/0b9cf2f75d41 User: Marek Fukala <mfukala@netbeans.org> Log: #244697 - CssFileModel$LazyEntry is a static inner class so it doesn't hold the CssFileModel itself
*** Bug 249469 has been marked as a duplicate of this bug. ***
*** Bug 252812 has been marked as a duplicate of this bug. ***