Closed Bug 15820 Opened 20 years ago Closed 20 years ago

[DOGFOOD]MLK: every ImageManagerImpl leaks

Categories

(Core :: ImageLib, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: warrensomebody, Assigned: neeti)

References

Details

(Whiteboard: [PDT-])

Bloaty: Refcounting and Memory Bloat
Statistics

|<-------Name------>|<--------------References-------------->|<----------------
Objects---------------->|<------Size----->|
                               Rem    Total      Mean       StdDev       Rem
Total      Mean       StdDev Per-Class      Rem
 257 ImageManagerImpl           93       93 (   47.00 +/-    46.33)        1
1 (    1.00 +/-     0.00)       12       12
Status: NEW → ASSIGNED
Target Milestone: M11
Summary: [leak] every ImageManagerImpl leaks → [DOGFOOD][leak] every ImageManagerImpl leaks
How much, 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:
ImageManagerImpl: 12 bytes/instance, and total leak of 12 bytes.
*** Bug 14439 has been marked as a duplicate of this bug. ***
Summary: [DOGFOOD][leak] every ImageManagerImpl leaks → [DOGFOOD]MLK: every ImageManagerImpl leaks
Whiteboard: [PDT-]
This leak not big enough for dogfood.  Marking [PDT-]
Assignee: pnunn → neeti
Status: ASSIGNED → NEW
Neeti has a fix for this.
-pn
If it's the fix I submitted to you, then I approve the checkin.
Blocks: 17907
Will need to make ImageManagerImpl a service. Moving tfv to M12.
Blocks: 18471
Blocks: 18951
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
This was fixed by making ImageManagerImpl a service on windows, mac and gtk
Blocks: 20203
Warren,

Does neeti's fix address this memory leak to your full satisfaction, or shall I
just rubber-stamp this as verified?

Thanks!
You can verify by looking at the tinderbox logs on coffee. You should see that
not every ImageManagerImpl leaks. Let me know if you can't verify this.
Putting aside for a moment the fact that I don't know what I'm doing ;)...

...from the current BloatView on Seamonkey Tinderbox for ImageManagerImpl, using
a depend build from 11.29 1:06 PM:

 	Per-Inst   Leaked    Total      Rem      Mean       StdDev     Total
         12        0        1        0 (    0.50 +/-     0.87)       18

Rem      Mean       StdDev
 0 (    3.33 +/-     2.66)

-----

So, it's still leaking 12 bytes when it leaks, but the mean is down by over an
order of magnitude. (I'm not sure what it's the mean _of_, however. ;)

Warren says?
I'm still seeing native image data leak when laoding a page with images in
appruner, then closing teh window (you can see this in ZoneRanger). It may not be
this specific bug, but it's very serious.
Simon,

Is the ImageURLImpl class leaking leaking? If not, can you give me the name of
the class which is leaking?
Eli: The Total column is the number allocated, Rem is the number remaining which
is 0, so this isn't leaking any more. Thanks for checking. Now you'll know how
to verify the next one.

Simon: You should report a new bug against Pam about mac native image data
leaking.
Status: RESOLVED → VERIFIED
Rubber-stamping as verified.

(Warren's effort is appreciated; browser QA has been suggested not to verify
memory leak bugs.)
No longer blocks: 17907
No longer blocks: 18471
No longer blocks: 18951
No longer blocks: 20203
You need to log in before you can comment on or make changes to this bug.