A memory leak exists in the
net.sf.colorer.eclipse.editors.ColorerEditor.
In the constructor, a double click listener is added to
the contentOutliner but is never removed. Because the
contentOutliner is memorised in the backgroundUpdater,
all the fields of the ColorerEditor cannot be destroyed
by the gc when the editor is closed, in particular the
editor site that retains many values.
I propose to add the remove of the double click
listener in the dispose method.
Logged In: YES
user_id=313042
Just tested it with IDE,
each backgroundUpdater Thread is destroyed when outliner is
going to be detached. Thus each ColorerEditor successfully
reaches its dispose() method.
Possibly you've had another kind of usecase? I didn't found
any leakage...
Logged In: YES
user_id=1508655
Ouch... I have, finally, found some useful information for
this problem.
Actually, you can reproduce the problem by opening any file
with the colorer editor plugin but WITH THE OUTLINE VIEW
CLOSED !!!
In this case, the detach() method of the
ColorerContentOutlinePage is never called and the background
updater thread remains active!!! as you can see if you put a
breakpoint in the ColorerEditor.dispose() method and you
examine the active threads in the 'main' ThreadGroup by
watching the expression Thread.currentThread(). So, the
problem (and the solution) has nothing to do with the double
click listeners.
I have added the following line at the beginning of the
ColorerEditor.dispose() method and this solves the problem:
...
if (null != contentOutliner) {
contentOutliner.detach()
}
...
Logged In: YES
user_id=313042
Ouh, indeed I see it now too ;)
First time I've tested this usecase but didn't checked that
the Thread should be destroyed.
Thanks alot for great report, fixed within 726 checkin
(http://svn.sourceforge.net/colorer/?rev=726&view=rev)