123034 - Xfree86 hogs CPU when certain characters encountered

Status: RESOLVED INCOMPLETE

(Core :: Layout: Text and Fonts, defect)

Description

[Devin Bayer]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20020112
BuildID:    20020112

I don't know why yet, but Apache is sending a bunch of wierd (>128) characters
and they crash mozilla.  I used a trial and error process to reduce the the
resultant to file to as small as possible.  I don't trust cutting and pasting
the characters (wouldn't want to crash other's when trying to view the bug) so
here are the ASCII values I got from glimmer: -38,-70,-39,-115
And here are the hex from khexedit: da, ba, d9, 8b, 0a

They need to come in order, but in any part of the file it makes the XFree86
process hog all the CPU and very very nearly make the computer unusable until
mozilla is killed (with -KILL).

I realize these are most definitally illegal characters, but it shouldn't make
mozilla crash.

Reproducible: Always
Steps to Reproduce:
Open page with those characters


Actual Results:  Dead in the water.

Expected Results:  Mozilla should have said: "Excuse me sir, but I don't think
that page is valid.  Please fix it."

Mozilla gives no error message, nor does X.  I will now proceed to fix the
source of the problem.

Comment 1

[Devin Bayer]

Attachment: Don't click it unless you are prepared for Mozilla to crash.

If you want to see if this crashes your build, then have an xterm availible
with "killall -9 mozilla-bin" already typed in.  After mozilla freezes, you'll
have about 1 second every 20 to do something.  Use it to press ENTER when the
xterm has focus.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Testcase loads fine for me, XFree86 4.0.1, using xfs, mozilla build 2002-02-01
morning on Linux.

Comment 3

[Andrew Schultz]

Worksforme with 1-31-2002 build and also 1-14-2002 build.
XFree86-4.1.0-15 with xfs under RH linux.

Comment 4

[Devin Bayer]

With 2002012814 I am experiencing a similar behavior.  Instead of freezing
indefinitally it is only for 49 seconds.  Then the page is displayed correctly.
 Subsequent reloading of effected page in same browser session yields expected
behavior.
Under debian, XFree 4.1.0-9 with internal font engine.  GTK 1.2.10-9.

Comment 5

[timeless]

w2k's notepad says those characters include bidi direction markers.  so this is 
either a bidi problem, or an intl detection problem. [my bet is the latter, but 
i'm going to ask the former to do the analysis]

Comment 6

[Simon Montagu :smontagu]

Notepad seems to be interpreting the data as UTF-8, which means that these four
bytes are displayed as two Arabic characters: 06BA;ARABIC LETTER NOON GHUNNA and
064D;ARABIC KASRATAN. 

Unless you have the default encoding set to UTF-8 in Mozilla, this isn't a Bidi
problem.

Comment 7

[Devin Bayer]

I had the defaut character encoding set to UTF-8.  But I've tested it on both
0.9.7 and 2002012814
 with the Western character set and am experiencing the same behavior as when
they were set to UTF-8.

Comment 8

[Vadim Berezniker]

Does this still happen with a recent nightly?

I've tried setting my Character Coding to UTF8 but the attachment loads
instantly without a freeze. 

Comment 9

[Devin Bayer]

I am still experienceing buggy behavior but it is not nearly as bad.  The
browser only takes about 5 seconds of 100% cpu utilization before displaying the
attachment.  Then I see a wierd double forward very small slash and a very small
curved inward u.  build 20020412.

Comment 10

[Azrael AOD]

sounds confirmed with enough info to be set 'new'

Comment 11

[Boris Zbarsky [:bzbarsky]]

Sounds like more "when we see a weird char we have to look for a font for it and
X is butt slow to do that" stuff.....

Comment 12

[Mats Palmgren (inactive)]

Does the problem still occur in a Nightly build?
http://nightly.mozilla.org/