Bug 12103 - LEAK: Fix the leaking ImageBuffer buffers on TOT
Summary: LEAK: Fix the leaking ImageBuffer buffers on TOT
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P1 Normal
Assignee: Nobody
URL:
Keywords: Regression
Depends on:
Blocks:
 
Reported: 2007-01-03 10:52 PST by Eric Seidel (no email)
Modified: 2007-01-06 20:28 PST (History)
1 user (show)

See Also:


Attachments
the fix (9.40 KB, patch)
2007-01-03 10:53 PST, Eric Seidel (no email)
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2007-01-03 10:52:47 PST
Fix the leaking ImageBuffer buffers on TOT

I can't test this due to the ASSERT SVGImage/Loader regression on TOT.  Someone else should land this as I'm about to get on a plane.
Comment 1 Eric Seidel (no email) 2007-01-03 10:53:15 PST
Created attachment 12190 [details]
the fix
Comment 2 Eric Seidel (no email) 2007-01-03 10:54:35 PST
ccing WildFox.  I figure he might be curious about the leak.
Comment 3 Darin Adler 2007-01-03 11:21:44 PST
Comment on attachment 12190 [details]
the fix

The SVGAnimateTransformElement.cpp change seems good, but unrelated.

I'd prefer to keep to a minimum the number of new functions that return an object that you're obliged to delete. A good way to indicate that is to use auto_ptr<X> instead of X*. That's not so common because normally we use Shared and RefPtr. Perhaps ImageBuffer should be Shared and then we could return a PassRefPtr.

No need to do the if statements in ~ImageBuffer. Both CGImageRelease and fastFree already do checks for null.

The private constructor that takes ownership of a GraphicsContext should take an auto_ptr<GraphicsContext> parameter to indicate it takes ownership.

Also, I'd suggest that the declaration of the private constructor not be CG_specific, even if the implementation has to be.

OwnPtr is to auto_ptr as RefPtr is to PassRefPtr.

r=me
Comment 4 Eric Seidel (no email) 2007-01-03 12:45:10 PST
It would be best if someone else landed this (applying darin's suggestions if they so desire).
Comment 5 Darin Adler 2007-01-06 20:28:05 PST
Committed revision 18641.