Bugzilla – Full Text Bug Listing
| Summary: | Resource leak in FadeIn class | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Boris Stepanov <bstepanov> | ||||
| Component: | GEF-Legacy GEF (MVC) | Assignee: | Alexander Nyßen <nyssen> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | justin.dolezy, nyssen | ||||
| Version: | 3.4 | ||||||
| Target Milestone: | 3.6.0 (Helios) M7 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Getting this on Mac OS X too.
The paintFigure(Graphics) method is the offender, as it calls getLocalBackgroundColor() without disposing the resource created.
int fillColor = pData.getPixel(getLocalBackgroundColor().getRGB());
There's also two more Color instances leaking due to the Figure.paint(Graphics) method calling getLocalBackgroundColor():
public void paint(Graphics graphics) {
if (getLocalBackgroundColor() != null)
graphics.setBackgroundColor(getLocalBackgroundColor());
Seeing as there's 6 frames, that's 18 Color objects leaked every time a guide fade in occurs.
Surely not an insignificant leak, no?
Created attachment 164783 [details]
Patch for SnapFeedbackPolicy
From the current implementation I cannot infer why getLocalBackgroundColor needs to be overwritten. Call hierarchy shows that getLocalBackgroundColor is only called by FadeIn.paintFigure(), Figure.paint(), and PrintFigureOperation.preparePrintSource. I think the latter two are not relevant for the fading-in of the guides, thus the creation of a mixed background color (as done within overwritten getLocalBackgroundColor) could IMHO also be placed in a private helper method that gets called from FadeIn.paintFigure() alone. This way the
disposal of the color could as well be exclusively taken care of within FadeIn.paintFigure().
I have attached a patch for the current HEAD that incorporates those changes and thus fixes the reported memory leak. On my machine (MacOS X) I can verify that Snap to Geometry on the GEF logic example does indeed not seem to be affected by the changes. Snap to Guide however does not work with the logic example on my machine (which seems to be caused by another Mac-specific issue; it does not work, neither with the patch nor without it), so I cannot verify it is unaffected as well. Could you please verify that the patch preserves the feedback painting behavior for Snap to Guides and Snap to Geometry?
Committed changes (subsumed by my attached patch) to HEAD. As stated within gef-dev mailing-list (http://dev.eclipse.org/mhonarc/lists/gef-dev/msg01296.html), Anthony verified as well that the desired snap-in behavior is preserved for snap-to-guide as well. |
Build ID: M20090211-1700 Steps To Reproduce: I use Sleak to monitor all SWT resources in my application. When I use a graphical editor I see resource leak in FadeIn class (Locates in SnapFeedbackPolicy.java). This class has method: public Color getLocalBackgroundColor() { return FigureUtilities.mixColors( super.getLocalBackgroundColor(), getParent().getBackgroundColor(), (double)opacity / FRAMES); } which creates new color resource each time, but nobody disposes all created resources. More information: