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.
Build: NetBeans IDE 8.0 (Build 201403101706) VM: Java HotSpot(TM) 64-Bit Server VM, 24.45-b08, Java(TM) SE Runtime Environment, 1.7.0_45-b18 OS: Mac OS X User Comments: leewilson86: Please will you just fix this problem! It has been around since Netbeans 6. Are you so lazy or imcompetitent that you cannot fix a memory leak? Please just fix it - it is well documented issue which has been around for years so you cannot be ignorant to it! Thanks Stacktrace: java.lang.OutOfMemoryError: GC overhead limit exceeded at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:300) at java.lang.StringCoding.encode(StringCoding.java:344) at java.lang.String.getBytes(String.java:916) at java.io.UnixFileSystem.getBooleanAttributes0(UnixFileSystem.java:0) at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242) at java.io.File.isDirectory(File.java:843)
Created attachment 146505 [details] stacktrace
org.openide.filesystems.FCLSupport$DispatchEventWrapperSingle 5 542 079 instances org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$FileEventImpl 4 435 158 instances org.openide.filesystems.FCLSupport$DispatchEventWrapperMulti 2 217 580 instances (I haven't been able to analyze the heap dump to find the biggest object, but it is probably FCLSupport.q). This is not a memory leak, to be exact. A huge number of file events is created in an atomic filesystem operation. These file events need to be stored and processed after the operation completes. In this case, these events consumed all available memory. What operations did you perform before the out-of-memory-error appeared? How many files do you have in your project? Thanks.
*** Bug 244077 has been marked as a duplicate of this bug. ***
This bug already has 5 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=208878
*** Bug 252056 has been marked as a duplicate of this bug. ***
*** Bug 251810 has been marked as a duplicate of this bug. ***
*** Bug 251759 has been marked as a duplicate of this bug. ***
Reports: 797268: Xmx=512m, probably too small for opened projects, otherwise nothing extraordinary 786827: Large MutualExclusionSupport#1 many files in some "uploads" directory 776136, 774653, 774310: There is lot of instances like DispatchEventWrapperSingle and FileEventImpl. The root of the problem could be in many instances of AsyncRefreshAtomicAction, all created for the same path. The bug could be somewhere in refreshFromGetter, issueIfExists, getFileObject of computeChildren, but it is not still clear to me why so many instances are created. (It could be also caused by some external operation.) Some steps to reproduce would be very helpful.
Created attachment 157144 [details] Patch for FolderChildren A scenario which may be related to reported bug is deleting whole directory with many files. In several places in the IDE, when a file-change listener is notified about deleted (or created or modified) file, the parent folder is refreshed. One solution is postponing of the refresh in case more events will come shortly. The patch contains example modifications for FolderChildren. (It should be reviewed and impact of the changes should be measured.) Unfortunately, I haven't managed to reproduce the bug with many events generated during (probably erroneously) repeated refresh of single folder.
> Some steps to reproduce would be very helpful. Do you have some folder with a lot of (thousands) subfolders in some of opened projects? Did you perform some operation with this folder (move, delete)? Thank you.
This bug already has 20 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=208878