DESCRIPTION: I took a quick look at nsStr leaks, and many of them seem to be coming from strings allocated in nsFontMetricsGTK::FindFont (it's not completely clear which ones). At least some of the problem seems to stem from the code: // XXX many of these statics need to be freed at shutdown time static PLHashTable* gFamilies = nsnull; static PLHashTable* gFamilyNames = nsnull; STEPS TO REPRODUCE: * run mozilla or mozilla-viewer with XPCOM_MEM_LEAK_LOG set to 1

The above patch fixes at least some of the leaks. It has the disadvantage that if one is using the profile manager, it frees everything after the profile manager is done (and then again at the end). This could be fixed by making nsFontMetricsGTK observe XPCOM shutdown, and a little more stuff (since the observer would be notified before all the nsFontMetricsGTK are gone, I think).

Thanks, David. We probably want to have a proper shutdown from XPCOM in the future, but this is a good start.

David, I rewrote part of nsFontMetricsGTK.cpp, and as part of that I switched to nsHashtable, and I've written the code to free those as well. I will check it in for M16.

Note to self: should test http://www.excite.com/ when verifying this bug...

David, do you want to take this? You seem to have looked at it already and Erik won't be back until late August, which is rather late in the nsbeta3 cycle if we want this to get in (assuming it hasn't already been checked in; Erik's comments are a bit ambiguous).

nsbeta3+ per ftang/jaimjr . It is a dup 5547, right ?

P1 nsbeta3+ per i18n bug meeting. prevent find other leaking bug.

We cannot fix all leaks. We need to know if this is a big leak. Moving to P4 unless a large leak can be determined. We cannot take time to clean up all noise now. Moving to P4. Adding [PDTP4]

nsbeta3- this for now. If we have the fix , then we will reconsider it.

Reassigning to Brian.

I'm not sure if this is still a problem or if Erik fixed it.

until we can build a purify version I don't know how to verify it is fixed.

move to moz0.9.3 since this is not critical to moz0.9.2

mark this as future

This bug is about freeing memory on shutdown. As far as I can tell the problem is (mostly?) solved but we need to verify it. This never was a run-time memory bloat issue. Bug 92580 appears to be about about runtime memory usage which is unrelated to this bug so I am removing the "blocks bug 92580". Is there a tracking bug about not freeing memory on shutdown? If so, this could be attached there.

--> ftang

bulk move NEW FUTURE bug to ASSIGN

katakai- can you take this bug?

gfx/src/gtk/ has been removed on trunk. This bug doesn't look like a branch candidate to me. -> WONTFIX