Missing unicode (japanese) glyphs create 80-meg memory leak



Core Graveyard
GFX: Gtk
15 years ago
10 years ago


(Reporter: Alexey Spiridonov, Assigned: blizzard)


Firefox Tracking Flags

(Not tracked)




(1 attachment)



15 years ago
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

Comment 2

15 years ago
This is a dup of another bug.  Do you see on a regular basis when using the main
google search page?

Comment 3

15 years ago
No, I use the standard English Google main page, and hence, there is never a

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.

Comment 4

15 years ago
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.

Comment 5

15 years ago
Do you happen to use xft?

Comment 6

15 years ago
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

Comment 7

14 years ago
Haven't used GTK1 moz for a long time, consequently haven't seen the bug. Looks
like it's time to close it.
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 8

14 years ago
No fix specified.

Resolution: FIXED → ---


14 years ago
Last Resolved: 14 years ago14 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.