Community
Participate
Working Groups
Build I20040226 1. Create a simple project P; create a file file.txt. 2. Open file.txt; close file.txt Using a profiler, check if there are any instances hanging around. I discover a left-over editor. In addition, I leak many ActionHandler and HandlerSubmissions (equal number). (I appear to leak 1 additional editor and N ActionHandler and HandlerSubmission instances for each pair of open/close operations) (I can also cause this with the java editor)
Raised the priority to critical: in addition to needing to fix this to ship, this adds noise to our current cross-eclipse memory analysis.
Chris, can you have a look at this ASAP please? I can help chase down refs this afternoon.
With the latest from HEAD, tried openning and closing 10 plain text editors. Looked for leaked EditorPane objects, there were 10. The path to each looks like: All GC Roots -> org.eclipse.ui.internal.EditorPane #136099: Direct Paths | +---org.eclipse.ui.internal.Workbench (#74317) [Java Frame] | +---windowManager org.eclipse.jface.window.WindowManager (#75352) | +---windows java.util.ArrayList (#76130) | +---elementData java.lang.Object[10] (#76364) | +---[0] org.eclipse.ui.internal.WorkbenchWindow (#105197) | +---pageListeners org.eclipse.ui.internal.PageListenerList (#105255) | +---listeners org.eclipse.jface.util.ListenerList (#105313) | +---listeners java.lang.Object[31] (#114326) | +---[19] org.eclipse.ui.internal.commands.ws.WorkbenchCommandSupport$1 (#75348) | +---this$0 org.eclipse.ui.internal.commands.ws.WorkbenchCommandSupport (#74316) | +---handlerSubmissionsByCommandId java.util.HashMap (#75347) | +---table java.util.HashMap$Entry[256] (#133887) | +---[0] java.util.HashMap$Entry (#133888) | +---value java.util.ArrayList (#134093) | +---elementData java.lang.Object[10] (#134346) | +---[1] org.eclipse.ui.commands.HandlerSubmission (#136137) | +---activeWorkbenchSite org.eclipse.ui.internal.EditorSite (#135926) | +---pane org.eclipse.ui.internal.EditorPane (#136099)
+1 We not only leak the last editor (plus all its actions) but every single editor that got opened (see bug 54594). Looking at the reference graphs (see attachements) it looks like the command support is responsible for this. Any ETA for the fix?
*** Bug 54594 has been marked as a duplicate of this bug. ***
Created attachment 8570 [details] Reference graph for a text editor action after closing the text editor
Created attachment 8571 [details] Reference graph for the CU editor after closing it Note Most of the fields named f* are links from the not yet freed editor actions.
Yesterday I fixed the command and context support to clean up HandlerSubmission and EnabledSubmission instances once the editor closes. We ran OptimizeIt on opening and closing a text editor and the only diff was some java.* and sun.* objects. I tried it with a java editor, and while there the HandlerSubmission and EnabledSubmission instances are cleaned up, it seems we are still hanging on to an EditorPane and some other related instances. I don't know why yet but I will look into it. This problem was probably introduced as part of bug 53673, recently the editor code was completely severed to abstract out the presentation.. (i.e. this area took a lot of damage recently)
*** Bug 55293 has been marked as a duplicate of this bug. ***
Chris, let me know if you need help on this on the (Java) editor side.
*** Bug 55272 has been marked as a duplicate of this bug. ***
*** Bug 55271 has been marked as a duplicate of this bug. ***
*** Bug 55269 has been marked as a duplicate of this bug. ***
*** Bug 55174 has been marked as a duplicate of this bug. ***
Thanks Dani for the offer, and sorry about the delay. There were actually a bunch of leaks all related to the new presentation code we've recently added (bug 53673). I fixed about five on the weekend. That being said, the remaining leak (in this mornings build) on CompilationUnitEditor seems to be JDT-UI, and in the area of the outliner. JavaOutlinePage creates a CustomFiltersActionGroup that is not properly disposed. I will attach a patch for JavaOutlinePage which, according to my test using Yourkit, fixes leaks of CompilationUnitEditor. I'll keep this bug assigned to me until I know that your leak test passes with this fix. (perhaps there are other important instances leaking..) Here is the first path (using 'yourkit'): GC Roots -> Object CompilationUnitEditor #002eb6fb: Reverse Paths | +---org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor (#002eb6fb) | +---fTextEditor of org.eclipse.ui.texteditor.TextOperationAction (#013e0eb7) | +---fUndo of org.eclipse.jdt.internal.ui.javaeditor.JavaOutlinePage (#00d1afd3) | +---this$0 of org.eclipse.jdt.internal.ui.javaeditor.JavaOutlinePage$JavaOutlineViewer (#011dad60) | +---fViewer of org.eclipse.jdt.ui.actions.CustomFiltersActionGroup (#00f41b6e) | +---this$0 of org.eclipse.jdt.ui.actions.CustomFiltersActionGroup$2 (#0113a42f) | +---[0] of java.lang.Object[3] (#01a13aae) | +---listeners of org.eclipse.jface.util.ListenerList (#0149d4f7) | +---listeners of org.eclipse.ui.internal.ViewPane$PaneMenuManager (#0030a37b) | +---isvMenuMgr of org.eclipse.ui.internal.ViewPane (#015b8520) | +---[4] of org.eclipse.swt.widgets.Listener[12] (#01f5ada6) | +---listeners of org.eclipse.swt.widgets.EventTable (#01d2336a) | +---eventTable of org.eclipse.swt.custom.ViewForm (#018ddfe2) | +---[243] of org.eclipse.swt.widgets.Widget[2048] (#00010f8c) | +---widgetTable of org.eclipse.swt.widgets.Display (#01f528ab) [Java Frame]
Created attachment 8761 [details] patch to JavaOutlinePage
I've released a change which will clean up any listeners registered on a SubMenuManager when it's disposed. This allows the Workbench to cover for the case where parts or pages don't properly remove their listeners. See bug 55592 for details.
To clarify, the issue in JavaOutlinePage's CustomFiltersActionGroup is that it was hooking a menu listener on the page site's menu manager and not removing it, because the group was not being disposed. The Workbench will now cover for this case, but JavaOutlinePage should still be changed to dispose all its action groups in case there are other listeners/resources needing attention.
using kevin's optimizeit and nick's change, the diff shows no leaks from opening and closing java editors. i'm going to mark this as fixed, please reopen if necessary. (jdt will probably still want to apply the patch..)
inspite of our testing yesterday, it seems JDT-UI's leak test is still failing in the latest build, though we haven't heard from anyone over there recently about the leak and i know there were build issues this morning.. can someone from JDT-UI enlighten us as to nature of their test or the reasons their test might still be failing? is this a real problem still? thanks guys.
Thomas, can you please comment on comment #20
Just tested I200403230800 with OptimizeIt and saw the leak like the test does. The leak can only be seen if the last editor is closed: 1. open a workspace which has *.java files but nothing is open 2. open one of the *.java files in the CU editor 3. close the CU editor ==> one instance of CompilationUnitEditor stays This is the scenario that the test performs. After doing so it tests whether there are still references to CompilationUnitEditor (from the roots). Note: when opening another editor the leak is gone i.e. there's still one editor listed and not two.
wow. this is strange. i profiled platform-ui head and jdt-ui head (including the patch i attached here yesterday). I use yourkit 2.0.1 for linux. Without the patch, I started, opened one java editor, closed one java editor, took a snapshot, looked up 'CompilationUnitEditor' (Ctrl+N) and found one instance. I searched paths to the root (Ctrl+P) and found about 20 or so (all passing through ViewPane's menu code) I retried using the patch and found no paths to the root. If someone over there uses Yourkit, can you send me all paths to root of CompilationUnitEditor after the open/close?
I could provide OptimizeIt output later tonight (MET) if that helps.
I tracked it down: you didn't see the leak because it is caused by new code that we released for I200403230800 . I've fixed it but since this does not prevent us from testing I will submit the fix during the fix pass.
Fix will go into I200403240800
