288143 - Browser goes into infinite loop while processing HTML font attribute

Status: VERIFIED FIXED

(Core Graveyard :: GFX: Gtk, defect)

Description

[andys]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

The Mozilla browser goes into an infinite loop when trying to process an HTML
page in *nix with the element/attribute pair <font face="a,a,a,...,a,a"/>, where
the number of faces is greater than 2^16. This is due to the way that font faces
are processed in FindStyleSpecificFont(PRUint32 aChar) in file nsFontMetricsGTK.cpp.

The number of font faces (mFonts.Count()) is allowed to be greater than 2^16
while the counter mFontsIndex in the processing loop is of type PRUint16. When
looping through the faces, mFontsIndex is incremented with the statement
mFontsIndex++. If there are more than 2^16 font faces, mFontsIndex eventually
returns to 0, and the loop never ends.

Reproducible: Always

Steps to Reproduce:
1. Create HTML page containing element/attribute pair <font
face="a,a,a,...,a,a,a"/>, where the number of faces is greater than 2^16;
2. Load HTML page into Mozilla browser on *nix.

Actual Results:  
Mozilla went into an infinite loop and did not respond, taking up more and more
CPU. Mozilla then had to be killed.

Expected Results:  
Mozilla should have processed the fonts without error.

Comment 1

[Ng Ming Hong]

IMO the severity should be set as "enhancement" as it is nearly impossible to
have 2^16 fonts installed...

Comment 2

[Frank Wein [:mcsmurf]]

(In reply to comment #1)
> IMO the severity should be set as "enhancement" as it is nearly impossible to
> have 2^16 fonts installed...

Of course this doesn't make sense ;), but it shouldn't be possible so to hang
Mozilla with such faulty html.

Comment 3

[Justin Wood (:Callek)]

Could you please attach a "minimal" testcase with this issue...

minimal as in, 2^16+5 or so fonts specified and minimal html.

This will help me (or more likely, someone else) be able to find where the
problem is and possibly fix this.

Also a link of at least one "production" page which this is a problem on will
help boost it on developers priority list, I believe.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase (100000)

Comment 5

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

Compiled and tested on GTK1, but not on the other platforms.
GTK2 is not affected.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 187220 [details] [diff] [review]
Patch rev. 1

r+sr=dbaron if you fix mGenericIndex in nsFontMetricsOS2.h and
nsFontMetricsWindows.h

(And there are no object size changes for any of these changes either!)

Comment 7

[Mats Palmgren (inactive)]

Attachment: Patch rev. 2

Updated as David requested.

Comment 8

[Benjamin Smedberg]

Comment on attachment 187251 [details] [diff] [review]
Patch rev. 2

a=me, I'll land this ASAP.

Comment 9

[Benjamin Smedberg]

fixed on trunk

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

Using build 2005-07-07-06 on Windows XP SeaMonkey trunk, it took around 47
seconds on a 3.2 GHz Intel Pentium 4 HT with 1 GB of PC 2700 DDR RAM, but no
long-term hang.  (Oddly enough, IE simply displays the HTML inline rather
instantaneously.)

Verified FIXED