gfxTextRunCache not cleaning up memory on shutdown

RESOLVED FIXED

Status

()

defect
--
minor
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: ajschult784, Assigned: bzbarsky)

Tracking

({memory-leak})

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(1 attachment)

nye bloat tbox showed a RLk change from 2KB to 22KB while it was down.  Relevant chunk from the log is

TOTAL                                         22528     939.11%
nsStringBuffer                                 9800   17400.00%
gfxTextRun                                     6624          -
gfxFont                                        2072          -
gfxFontGroup                                   1920          -

I verified that the leaks are due to bug 356235
I don't think that these are real leaks; this is the the textrun cache not cleaning things up after itself on shutdown -- it's just a global object that gets allocated on the heap and is never freed.
Severity: major → minor
Summary: Leaking boatloads of gfxTextRuns → gfxTextRunCache not cleaning up memory on shutdown
So the problem with doing this is that this cache lives in a static lib, not in a module... ;(

I've hacked my layout module to delete the cache on shutdown so I can debug other leaks, for the time being.  But that's not good enough for checkin.
Note that Roc's new textframe patch does not use the textRunCache.
Blocks: 361700
Depends on: 333659
OK, roc says he's not planning to actually remove this cache.  So we need to fix this bug so we have reasonable leak numbers.

This patch makes consumers of the static lib actually init and shut down the cache if they want it to work.
Attachment #252257 - Flags: superreview?(roc)
Attachment #252257 - Flags: review?(vladimir)
Attachment #252257 - Flags: superreview?(roc) → superreview+
Comment on attachment 252257 [details] [diff] [review]
Propoposed fix

r=me, thanks!
Attachment #252257 - Flags: review?(vladimir) → review+
Assignee: vladimir → bzbarsky
Checked in.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
I know I reviewed this, but is there a reason why we didn't just add the textrun cache Init/Shutdown to nsThebesGfxFactory? The module destructor does get called, right?
We could do that, sure.  The point was that we needed it in _some_ module.  And only one module.  But one guaranteed to be instantiating this cache, which lives in a non-module lib....
You need to log in before you can comment on or make changes to this bug.