Bug 47786 - Possible leak in TextMergeViewer
Summary: Possible leak in TextMergeViewer
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Compare (show other bugs)
Version: 3.0   Edit
Hardware: All All
: P2 major (vote)
Target Milestone: 3.1 M4   Edit
Assignee: Andre Weinand CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-12-01 06:04 EST by Thomas M??der CLA
Modified: 2004-11-22 10:04 EST (History)
1 user (show)

See Also:

Attachments
Contains html document that shows path to GC root object from Document that is not being freed (6.02 KB, application/x-zip-compressed)
2004-11-03 05:29 EST, Babar Ali CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas M??der CLA 2003-12-01 06:04:33 EST 
Eclipse M5

1) Import junit 3.8.1 as in the Smoke test
2) Select junit.awtui.AboutDialog
3) Select refactor->rename from the context menu
4) Enter "AboutDialog2" as the new name
5) Press the preview button
6) press ok

TextMergeViewer adds a IDocumentListener (instance variable fDocumentListener)
that doesn't seem to be cleaned up in this case.
Comment 1 Babar Ali CLA 2004-11-02 11:33:25 EST 
Additional info about compare leak.  
Following objects are left when you close the compare window. Some of them are
required to stay in memory but any of following with head count equal to 3 or
multiples of 3 are increased each time you run compare and close window. These
results are of after running GC explicitly.

I am interested to know if there are immediate plans to fix it.

 profiler>*****GC Finished with:
	---- used_objects: 489495	---- used_object_space: 8713664
Class Name: org.eclipse.compare.internal.TextMergeViewerCreator, Objects Left: 1
Class Name: org.eclipse.compare.contentmergeviewer.TextMergeViewer, Objects Left: 3
Class Name: org.eclipse.compare.contentmergeviewer.TextMergeViewer$4, Objects
Left: 3
Class Name: org.eclipse.compare.internal.MergeSourceViewer, Objects Left: 9
Class Name: org.eclipse.compare.contentmergeviewer.TextMergeViewer$24, Objects
Left: 3
Class Name: org.eclipse.compare.contentmergeviewer.TextMergeViewer$26, Objects
Left: 3
Class Name: org.eclipse.compare.contentmergeviewer.TextMergeViewer$27, Objects
Left: 3
Class Name: org.eclipse.compare.contentmergeviewer.TextMergeViewer$28, Objects
Left: 3
Class Name: org.eclipse.compare.contentmergeviewer.TextMergeViewer$2, Objects
Left: 3
Class Name: org.eclipse.jface.text.DocumentCommand, Objects Left: 9
Class Name:
org.eclipse.compare.contentmergeviewer.TextMergeViewer$HeaderPainter, Objects
Left: 3
Class Name: org.eclipse.compare.contentmergeviewer.TextMergeViewer$25, Objects
Left: 3
Class Name:
org.eclipse.compare.contentmergeviewer.TextMergeViewer$ChildPositionUpdater,
Objects Left: 3
Class Name: org.eclipse.compare.contentmergeviewer.TextMergeViewer$Diff, Objects
Left: 90
Comment 2 Andre Weinand CLA 2004-11-02 11:44:30 EST 
Will look into that...
Comment 3 Babar Ali CLA 2004-11-03 05:29:12 EST 
Created attachment 15590 [details]
Contains html document that shows path to GC root object from Document that is not being freed
Comment 4 Babar Ali CLA 2004-11-08 04:55:50 EST 
One thing that you need to do is to remove ContributionItems from toolbar manager.
Comment 5 Babar Ali CLA 2004-11-22 02:07:46 EST 
Any progress on this one ?
Comment 6 Andre Weinand CLA 2004-11-22 07:03:04 EST 
Yes, culprit is SourceViewer. fDocument is now nulled on dispose.
As a consequence SourceViewer.getDocument() returns null which makes
TextMergeViewer.unsetDocument leak a reference.
Will be fixed for N20041123.
Comment 7 Andre Weinand CLA 2004-11-22 10:04:46 EST 
fixed for N20041123