Community
Participate
Working Groups
Build id: M20110909-1335 1. Open the Synchronize view, do a Sychronize with patch 2. Remove synchronization 3. Repeat steps 1 and 2 several times to make the issue more apparent 4. Remove All Finishes operations in the Progress view. (This will workaround another occasional memory problem I've seen where the swt.Link holds a reference to a RefreshParticipantJob, I will open a separate bug). 5. Run GC, wait for a bit. 6. JobManager will still hold a references to the DiffTreeChangesSections, this can be seen with Eclipse Memory Analyzer The leak is much more severe using EGit (see Bug 352282) but the bug is the same. In MAT: 1. Search for .*ApplyPatchSubscriber.* in Dominator. 2. Right-click on one of the org.eclipse.team.internal.ui.synchronize.patch.ApplyPatchSubscriber 3. Merge Shortest paths to GC root, Exclude all phantom/weak/soft org.eclipse.core.internal.jobs.InternalWorker @ 0x160e5318 Worker-JM Native Stack, Thread '- manager org.eclipse.core.internal.jobs.JobManager @ 0x15edb090 '- jobListeners org.eclipse.core.internal.jobs.JobListeners @ 0x15edb410 '- global org.eclipse.core.runtime.ListenerList @ 0x15ee7340 '- listeners java.lang.Object[5] @ 0x1e53b588 '- [2] org.eclipse.team.internal.ui.mapping.DiffTreeChangesSection$1 @ 0x1e4b3c38 '- this$0 org.eclipse.team.internal.ui.mapping.DiffTreeChangesSection @ 0x1e4b3c50 Solution: DiffTreeChangesSection adds a JobChangeAdapter in its constructor but doesn't remove it. It should remove it in its dispose() method.
Created attachment 209711 [details] DiffTreeChangesSection memory leak patch
Thanks for the descriptive summary and the patch Marc! I will try to have a look at it next week.
Fixed with 62be766bed8025810531fe026ab3b1e233904b06, available in builds >= N20120131-2000. Thanks again Marc, nice catch!
Marc, could you verify the fix using one of the latest N-builds?
(In reply to comment #4) > Marc, could you verify the fix using one of the latest N-builds? I tested with eclipse-SDK-N20120205-2000 and it looks good. I don't see any more instances of ApplyPatchSubscriber accumulating because of this. I also tested with EGit 1.3.0.201202051215 and the behavior is similar. I will create separate bugs for the 2 remaining issues mentioned in bug 352282 comment 5 once I have done further investigation.
Awesome, thanks again. Marking the bug as verified.