Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 312594 - SnapshotImpl instance kept by ExecutionJob after closing the editor
Summary: SnapshotImpl instance kept by ExecutionJob after closing the editor
Status: RESOLVED FIXED
Alias: None
Product: MAT
Classification: Tools
Component: Core (show other bugs)
Version: 1.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Krum Tsvetkov CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-12 08:00 EDT by Krum Tsvetkov CLA
Modified: 2010-06-24 09:15 EDT (History)
0 users

See Also:


Attachments
Path keeping the SnapshotImpl alive (28.73 KB, image/png)
2010-05-12 08:06 EDT, Krum Tsvetkov CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Krum Tsvetkov CLA 2010-05-12 08:00:36 EDT
I noticed that after closing the snapshot editor the SnapshotImpl instance is still kept in memory. Looking at the heap dump revealed that there is sometimes a QueryExecution$ExecutionJob still referenced by the eclipse ProgressManager. 

I'll attach a screenshot with the paths to the SnapshotImpl and will look into this problem.
Comment 1 Krum Tsvetkov CLA 2010-05-12 08:06:03 EDT
Created attachment 168125 [details]
Path keeping the SnapshotImpl alive

This is the path keeping the SnapshotImpl alive. I noticed that sometimes the job stays displayed in the "Progress" view. If this happens then our instance of ExecutionJob keeps the Editor and other resources. To be on the safe side I will "cleanup" the job after it is executed. By cleanup I mean setting the problematic fields to null
Comment 2 Krum Tsvetkov CLA 2010-05-12 08:14:45 EDT
I submitted the changes from comment 1. I'll keep the message open for a while to investigate why sometimes the jobs disappear and sometimes they are left in the list of the Process view.
Comment 3 Krum Tsvetkov CLA 2010-06-24 09:15:29 EDT
The ClassReferrersQuery kept a reference to the ProgressListener it initially received and reused it afterwards on every tree expansion (i.e. every time the IResultTree.getChildren() method is called). This is wrong, as the job for which the progress listener was created is already finished and the listener has reported "done".
I removed fully the usage of progress listener while expanding this tree. May be we should design our IResult subclasses like IResultTree to support progress information and pass a proper listener to them. However this will be an API change which I'm not sure we really need.

With this small change I think the reported bug is solved. I close the message now.