Bloaty: Refcounting and Memory Bloat Statistics |<-------Name------>|<--------------References-------------->|<---------------- Objects---------------->|<------Size----->| Rem Total Mean StdDev Rem Total Mean StdDev Per-Class Rem 276 ImageRequestImpl 365 365 ( 183.00 +/- 182.33) 365 365 ( 183.00 +/- 182.33) 24 8760

How much and how often?

We need more info to assist in PDT+ vs. PDT- decision. How bad is this leak? Thanks!

Running apprunner/mozilla. First site is mozilla.org, sample#2, sample#0: ImageRequestImpl: 24 bytes/instance, and total leak of 1368 bytes.

This leak not big enough for dogfood. Marking [PDT-]

The ImageRequestImpl which is created for the icon is leaking. Moving to m12

I looked at this... This one is due to a custom Release method. You can either: a) throw an NS_LOG_RELEASE macro into the Release method, or, b) (better yet), pull the custom stuff out of Release and into the destructor where it belongs. Then you can just use NS_IMPL_ISUPPORTS.

I had already removed the custom release method. This fixes some of the leaks. But the ImageRequestImpl which is created for the icon is still leaking. On loading res/samples/raptor.jpg or res/samples/rock_gra.gif in viewer, the ImageRequestImpl created for images is being released, but the ImageRequestImpl created for the icon is not released. On loading res/samples/anieyes.gif, there is only one ImageRequestImpl created (no icon) and this gets released properly. The ImageRequestImpl for the icon is being created from the DeviceContextImpl. ImageRequestImpl::ImageRequestImpl() line 174 DeviceContextImpl::LoadIconImage(DeviceContextImpl * const 0x010141d0, int 0, nsIImage * & 0x00000000) line 379 + 36 bytes nsImageFrame::DisplayAltFeedback(nsIPresContext & {...}, nsIRenderingContext & {...}, int 0) line 449 + 20 bytes nsImageFrame::Paint(nsImageFrame * const 0x01cef970, nsIPresContext & {...}, nsIRenderingContext & {...}, const nsRect & { On looking at the bloaty log, I find that there is one instance of DeviceContextImpl being leaked. It is posible that this is the DeviceContextImpl that it created from the webshell. In the bloaty log for viewer, we have one instance of webshell being leaked F:\seamonkey\mozilla\gfx\src>cvs diff -c cvs server: Diffing . Index: nsImageRequest.cpp =================================================================== RCS file: /cvsroot/mozilla/gfx/src/nsImageRequest.cpp,v retrieving revision 3.13 diff -c -r3.13 nsImageRequest.cpp *** nsImageRequest.cpp 1999/10/27 22:45:05 3.13 --- nsImageRequest.cpp 1999/11/08 19:55:54 *************** *** 176,181 **** --- 176,188 ---- ImageRequestImpl::~ImageRequestImpl() { + if (mXPObserver) { + // Make sure dangling reference to this object goes away + XP_RemoveObserver(mXPObserver, ns_observer_proc, (void*)this); + } + if (mImageReq) { + IL_DestroyImage(mImageReq); + } // Delete the list of observers, and release the reference to the image // request observer object if (nsnull != mObservers) { *************** *** 254,259 **** --- 261,268 ---- return NS_OK; } + NS_IMPL_ISUPPORTS1(ImageRequestImpl, nsIImageRequest); + /* NS_IMPL_ADDREF(ImageRequestImpl) NS_IMPL_QUERY_INTERFACE(ImageRequestImpl, kIImageRequestIID) *************** *** 272,277 **** --- 281,287 ---- } return mRefCnt; } + */ nsIImage* ImageRequestImpl::GetImage() cvs server: Diffing beos cvs server: Diffing gtk cvs server: Diffing mac cvs server: Diffing motif cvs server: Diffing os2 cvs server: Diffing photon cvs server: Diffing ps cvs server: Diffing qt cvs server: Diffing rhapsody cvs server: Diffing windows cvs server: Diffing xlib cvs server: Diffing xlibrgb

This bug has been fixed on linux. It is partially fixed on linux and Mac. But the ImageRequestImpl which is created for the icon is still leaking. Instances of ImageRequestImpl which are created for the icons by DeviceContextImpl::LoadIconImage(PRInt32 aId, nsIImage*& aImage) leak. Filed a separate bug for DeviceContextImpl leaks. See bug 19975

Moving this to M13, since this bug is dependent on 19975

Putting dogfood in the keyword field.

The ImageRequestImpl object and DeviceContextImpl are no longer being leaked on windows. |<------Class----->|<-----Bytes------>|<----------------Objects----------------> |<--------------References-------------->| Per-Inst Leaked Total Rem Mean StdDev Total Rem Mean StdDev 333 ImageRequestImpl 28 0 58 0 ( 22.76 +/- 13.65) 58 0 ( 22.76 +/- 13.65) 299 DeviceContextImpl 76 0 8 0 ( 2.50 +/- 1.86) 5686 0 ( 16.30 +/- 10.38)

Would anyone like to verify this memory leak, or shall I rubber-stamp it as Verified without inspection? Thanks!

With apologies to warren (and bruce, although he's not here), rubber-stamping as Verified without Inspection. [Warren, you tried to explain this by Bugzilla a while ago and I didn't quite grok. I'd be happy to verify these in actuality in the future if you'd like to sit down and spend 5-10 minutes explaining in person.]

Just look for the class in the bloat log on tinderbox. That will tell you if the leak (or mis-reporting) has been fixed.