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.
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) → superreview+
Comment on attachment 252257 [details] [diff] [review] Propoposed fix r=me, thanks!
Attachment #252257 - Flags: review?(vladimir) → review+
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.