RESOLVED FIXED 12103
LEAK: Fix the leaking ImageBuffer buffers on TOT
https://bugs.webkit.org/show_bug.cgi?id=12103
Summary LEAK: Fix the leaking ImageBuffer buffers on TOT
Eric Seidel (no email)
Reported 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.
Attachments
the fix (9.40 KB, patch)
2007-01-03 10:53 PST, Eric Seidel (no email)
darin: review+
Eric Seidel (no email)
Comment 1 2007-01-03 10:53:15 PST
Created attachment 12190 [details] the fix
Eric Seidel (no email)
Comment 2 2007-01-03 10:54:35 PST
ccing WildFox. I figure he might be curious about the leak.
Darin Adler
Comment 3 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
Eric Seidel (no email)
Comment 4 2007-01-03 12:45:10 PST
It would be best if someone else landed this (applying darin's suggestions if they so desire).
Darin Adler
Comment 5 2007-01-06 20:28:05 PST
Committed revision 18641.
Note You need to log in before you can comment on or make changes to this bug.