Closed Bug 34392 Opened 25 years ago Closed 17 years ago

nsStr leaked from nsFontMetricsGTK::FindFont

Categories

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

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: dbaron, Assigned: masaki.katakai)

Details

(Keywords: memory-leak)

Attachments

(1 file)

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
Status: NEW → ASSIGNED
Target Milestone: --- → M16
Target Milestone: M16 → M18
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...
Keywords: nsbeta3
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).
Whiteboard: (->dbaron?)
nsbeta3+ per ftang/jaimjr . It is a dup 5547, right ?
Whiteboard: (->dbaron?) → [nsbeta3+]
P1 nsbeta3+ per i18n bug meeting. prevent find other leaking bug.
Priority: P3 → P1
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]
Priority: P1 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP4]
nsbeta3- this for now. If we have the fix , then we will reconsider it.
Whiteboard: [nsbeta3+][PDTP4] → [nsbeta3-][PDTP4]
Reassigning to Brian.
Assignee: erik → bstell
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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.
Target Milestone: M18 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
move to moz0.9.3 since this is not critical to moz0.9.2
Whiteboard: [nsbeta3-][PDTP4]
Target Milestone: mozilla0.9.2 → mozilla0.9.3
mark this as future
Target Milestone: mozilla0.9.3 → Future
Blocks: 92580
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.
No longer blocks: 92580
--> ftang
Assignee: bstell → ftang
Status: ASSIGNED → NEW
bulk move NEW FUTURE bug to ASSIGN
Status: NEW → ASSIGNED
katakai- can you take this bug?
Assignee: ftang → katakai
Status: ASSIGNED → NEW
Component: GFX → GFX: Gtk
gfx/src/gtk/ has been removed on trunk.
This bug doesn't look like a branch candidate to me.

-> WONTFIX
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: