User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030713 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030713 I can only reproduce this on GTK-1.2 based mozilla (moz & firebird), starting from at least 1.4/0.6 (tried yesterday's firebird nightly). With GTK2, there is no problem. (However, GTK2 has a host of other issues -- general XUL slowness, bad WM_CLASS/role management, etc, so I prefer GTK1) You mustn't have fonts with Japanese glyphs installed for this to be reproducible. If you load this page (or other similar pages with missing glyphs, comment if you need more info on that), there will be a several-second slow-down, sounds of stuff paging to disk, and top will show Mozilla gobbling up memory. It stops around 120 megabytes, and renders the page. Predictably, this makes the browser very sluggish thereafter. Leaving the page does not free the memory. Here's a sample line from top (surprisingly high shared mem usage): 15789 lesha 12 0 109m 109m 98m S 0.0 43.6 0:23.94 MozillaFirebird Reproducible: Always Steps to Reproduce: Expected Results: Mozilla should not drastically increase memory consumption when unable to find these glyphs.
Assignee: font → blizzard
Component: Layout: Fonts and Text → GFX: Gtk
This is a dup of another bug. Do you see on a regular basis when using the main google search page?
No, I use the standard English Google main page, and hence, there is never a problem. I've seen it happen on: a) That japanese docs page. b) Another page, where KOI8-R is misdetected as Unicode, and hence it attempted to render some unknown glyphs. The latter even happened in 1.3 (and has nothing to do with Japanese per se -- the fonts were installed on that system). I may be able to get a base case based on b). If it's not a dupe (I didn't find anything similar), I will probably upload it sometime tonight.
Created attachment 128307 [details] A weak base case for the bug. I had messed around with the fonts on my machine last night (removing a number of badly hinted ones), and now the blow-up in memory consumption is about 30 megabytes on the sample URL (to 50 total). It's still very sluggish, however. I tried cooking up a base case, and the best I could do was the attached file with a few K of /dev/urandom output stuffed as UTF-8 text. This results in an 8-meg blow up on my system. For a 7K file, that's far too much. Hope this helps.
Do you happen to use xft?
Ok, it seems I wasn't as verbose as I should've been. When I use GTK2 + Xft + fontconfig, there is *no* problem. However, Mozilla is much slower with GTK2. If I use GTK1 without Xft, plain stock build of GTK 1.2.10 with a plain, stock build of Mozilla 1.4/Firebird 0.6/Nightly (as of 7/21), I see this memory leak problem.
Haven't used GTK1 moz for a long time, consequently haven't seen the bug. Looks like it's time to close it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
No fix specified. ->WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago → 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.