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.

Bug 243485 - OOME: Many FCLSupport$DispatchEventWrapperSingle instances
Summary: OOME: Many FCLSupport$DispatchEventWrapperSingle instances
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 8.0
Hardware: All All
: P2 normal (vote)
Assignee: Jaroslav Havlin
: 244077 251759 251810 252056 (view as bug list)
Depends on:
Reported: 2014-04-02 16:01 UTC by leewilson86
Modified: 2018-03-05 13:08 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 208878

stacktrace (2.91 KB, text/plain)
2014-04-02 16:01 UTC, leewilson86
Patch for FolderChildren (3.10 KB, patch)
2015-11-04 15:36 UTC, Jaroslav Havlin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description leewilson86 2014-04-02 16:01:28 UTC
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!


java.lang.OutOfMemoryError: GC overhead limit exceeded
   at java.lang.StringCoding$StringEncoder.encode(
   at java.lang.StringCoding.encode(
   at java.lang.String.getBytes(
Comment 1 leewilson86 2014-04-02 16:01:30 UTC
Created attachment 146505 [details]
Comment 2 Jaroslav Havlin 2014-04-04 15:27:59 UTC
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?

Comment 3 Jaroslav Havlin 2014-05-09 12:30:54 UTC
*** Bug 244077 has been marked as a duplicate of this bug. ***
Comment 4 Exceptions Reporter 2014-10-16 16:58:24 UTC
This bug already has 5 duplicates 
Comment 5 Jaroslav Havlin 2015-08-13 07:13:33 UTC
*** Bug 252056 has been marked as a duplicate of this bug. ***
Comment 6 Jaroslav Havlin 2015-08-14 06:29:52 UTC
*** Bug 251810 has been marked as a duplicate of this bug. ***
Comment 7 Jaroslav Havlin 2015-08-14 06:40:24 UTC
*** Bug 251759 has been marked as a duplicate of this bug. ***
Comment 8 Jaroslav Havlin 2015-11-03 16:41:33 UTC

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.
Comment 9 Jaroslav Havlin 2015-11-04 15:36:47 UTC
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.
Comment 10 Jaroslav Havlin 2015-11-06 10:23:04 UTC
> 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.
Comment 11 Exceptions Reporter 2017-10-05 12:05:43 UTC
This bug already has 20 duplicates