Closed Bug 15820 Opened 25 years ago Closed 25 years ago

[DOGFOOD]MLK: every ImageManagerImpl leaks

Categories

(Core :: Graphics: 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: 25 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.