Closed Bug 14439 Opened 25 years ago Closed 25 years ago

[DOGFOOD]MLK: The nsImageManager is not being deleted...

Categories

(Core :: Graphics: ImageLib, defect, P3)

All
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE of bug 15820

People

(Reporter: rpotts, Assigned: pnunn)

References

Details

hey patrick, I hear that you own GFX now :-) I'm running into lots of leaks because the nsImageManagerImpl is not a service and thus is not being deleted at shutdown. Since the ImageManager is not getting deleted, IL_Shutdown() is not being called. This means that the ImageLib cache of il_containers is not being released :-( -- rick
Assignee: beard → pnunn
Status: NEW → ASSIGNED
I'll look into making it a service. Advice is welcomed. -pn
how big is the leak?
Rick: I see the il_containers being released when the image request is released. Which is triggered in nsFrameImageLoader::StopImageLoad() when you move off a page and when you quit the browser. (Just a note, I'm looking at viewer, not apprunner.) Could you point out to me where the il_containers are leaking? I'm trying to hit the worst leaks first. If we are only leaking the image manager but not the containers, the leak may be dealt with alittle later. thnx, pn
Target Milestone: M11
hey pam, Inside of IL_GetImage(...) the ImagenetContext is Cloned twice and stored in the image_req->net_cx and the il_container->net_cx. I was seeing the reference held by the il_container staying around in the image cache. Since the ImageManager was not getting deleted, the cache was not getting cleared... So, these image containers were leaking... I think that if the ImageManager were destroyed then everything would get cleaned up correctly...
Blocks: 14516
Summary: MLK: The nsImageManager is not being deleted... → [DOGFOOD]MLK: The nsImageManager is not being deleted...
How big is this leak?
I believe that it depends on how big the cache of il_containers is... Basically, the problem is that the ImageManager is not an XPCOM service (because it was written before the service manager existed. The fix is to remove the global variable which references the ImageManager singleton and allow it's destructor to be called... This will call IL_Shutdown() in turn which will (among other cleanup) delete the image cache. I guess the real question is 'how important is it to call IL_Shutdown()' ?
How big is the leak? 10 bytes, 10Kbytes, 10Mbytes, 10Gbytes???
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Running apprunner/mozilla. First site is mozilla.org, sample#2, sample#0: ImageManagerImpl: 12 bytes/instance, and total leak of 12 bytes. This is a duplicate of bug#15820 *** This bug has been marked as a duplicate of 15820 ***
Remember that the 12 bytes is *only* for the ImagemanagerImpl instance... You also need to acocunt for all of the outstanding il_containers and other imagelib structs that leak as a result of not calling IL_Shutdown(...)
Status: RESOLVED → VERIFIED
[code-level bug; rubber-stamping as duplicate.] Bruce-san, please feel free to re-open if this conclusion is erroneous.
You need to log in before you can comment on or make changes to this bug.