34392 - nsStr leaked from nsFontMetricsGTK::FindFont

Status: RESOLVED WONTFIX

(Core Graveyard :: GFX: Gtk, defect, P4)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: proposed patch (at least part of problem)

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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).

Comment 3

[Erik van der Poel]

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

Comment 4

[Erik van der Poel]

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.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 6

[Hixie (not reading bugmail)]

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).

Comment 7

[Frank Tang]

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

Comment 8

[Frank Tang]

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

Comment 9

[leger]

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]

Comment 10

[Frank Tang]

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

Comment 11

[Erik van der Poel]

Reassigning to Brian.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 13

[kill this account]

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

Comment 14

[Frank Tang]

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

Comment 15

[Frank Tang]

mark this as future

Comment 16

[kill this account]

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.

Comment 17

[kill this account]

--> ftang

Comment 18

[Frank Tang]

bulk move NEW FUTURE bug to ASSIGN

Comment 19

[Frank Tang]

katakai- can you take this bug?

Comment 20

[Mats Palmgren (inactive)]

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

-> WONTFIX