Bug 394875 - Memory leak with trim control contributions
Summary: Memory leak with trim control contributions
Status: NEW
Alias: None
Product: RAP
Classification: RT
Component: Workbench (show other bugs)
Version: 1.5   Edit
Hardware: Macintosh Mac OS X
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-22 06:11 EST by Peter Kullmann CLA
Modified: 2012-11-22 06:11 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Kullmann CLA 2012-11-22 06:11:05 EST
RAP leaks when using a trim control contribution:

       <menuContribution
             locationURI="toolbar:org.eclipse.ui.trim.status">
          <toolbar
                id="mytoolbar">
             <control
                   class="org.example.MyControlContribution">
             </control>
          </toolbar>
       </menuContribution>

The actual contribution (subclass of WorkbenchWindowControlContribution) may be as simple as a Label. 

When a Workbench starts, it creates an org.eclipse.ui.internal.activities.Identifier instance for the contribution. The Identifier instance is the written to the static member "strongReferences" (defined in org.eclipse.ui.internal.activities.Identifier). When the workbench closes these Identifier instances are being removed from the strongReferences collection (usually by a method called unregisterVisibleWhen() that disposes an identifierListener). But not in the case of trim contributions. For these, the Identifier instance remains in the strongReferences collection and causes the Workbench including Windows, Shells and so on to remain on the heap.