275449 - Crash of Mozilla 1.7.5 and X server when viewing txt file containing PHP code.

Status: RESOLVED DUPLICATE of bug 244340

(Core Graveyard :: GFX: Gtk, defect)

Description

[John McWade]

This is using a downloaded rpm of mozilla suite (Mozilla 1.7.5
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217).
Downloaded this a mere 12 hours ago....
I've reproduced this 6 consecutive times by doing the following:
(I've put all necessary files for duplicating this situation(for me anyway) in
its own directory)

1. Go to uri http://www.opencsil.csiltaivzeen.net/bugzillatest/newmaya.csil
2. Click on "view php"
This leads to a txt file containing php code.

At this point the browser crashes as well as x server(with a 'caught signal 11)

Comment 1

[Hermann Schwab]

the document is served as text/plain, ISO-8859-1

First line as seen by Mozilla/Windows:

<? function show_form($value=��) { ?>  

Seems to contain invalid code:
The 'â€' sequence is shown in my text editor as 'â' followed by two black squares.

IrfanView HEXView shows: E2 80 9d

Comment 2

[Hermann Schwab]

Seems that switching to UTF-8 solves the problem, the line below seems more
reasonable:
UTF8      :  <? function show_form($value=””) { ?>
ISO-8859-1:  <? function show_form($value=��) { ?>



http://www.htmlhelp.com/reference/charset/   about ISO-8859-1
E2 decodes to â
80 9d is invalid, as hex 80 is decimal 128, and hex 9d is decimal 157

ISO-8859-1 explicitly does not define displayable characters for positions 0-31
and 127-159, and the HTML standard does not allow those to be used for
displayable characters.


http://www.pemberley.com/janeinfo/latin1.html#utf8

In UTF-8, each 16-bit Unicode character is encoded as a sequence of one, two, or
three 8-bit bytes, depending on the value of the character.

E2 80 9d decodes to hex 201d,
hex 201d is &#8221;  ” Right Double Quotation Mark (Double Comma Quotation Mark)

Comment 3

[Hermann Schwab]

Seems that switching to UTF-8 solves the problem, the line below seems more
reasonable:
UTF8      :  <? function show_form($value=””) { ?>
ISO-8859-1:  <? function show_form($value=��) { ?>



http://www.htmlhelp.com/reference/charset/   about ISO-8859-1
E2 decodes to â
80 9d is invalid, as hex 80 is decimal 128, and hex 9d is decimal 157

ISO-8859-1 explicitly does not define displayable characters for positions 0-31
and 127-159, and the HTML standard does not allow those to be used for
displayable characters.


http://www.pemberley.com/janeinfo/latin1.html#utf8

In UTF-8, each 16-bit Unicode character is encoded as a sequence of one, two, or
three 8-bit bytes, depending on the value of the character.

E2 80 9d decodes to hex 201d,
hex 201d is &#8221;  ” Right Double Quotation Mark (Double Comma Quotation Mark)

Comment 4

[John McWade]

I almost hesitate to mention that I am using Konqueror *shudder/wince* at the 
moment to access this site after the above-mentioned problematic browser 
crashed again (taking xserver with it) after viewing this very page, which 
loaded fine but crashed when I clicked "LOGIN" link below. 
 
I was not aware that the server is configured to iso-8859-1 so this is an 
interesting point, Hermann. 
 
Back to the browser however; one would admit, I think, that this is behavior 
which could be classified as 'undesirable.' I have accessed this page with no 
ill effects with previous mozilla releases (from FC1 & FC2 standard distros) 
as well as with Firefox, Epiphany, and at the moment Konqueror. So I suppose 
this leaves me wondering why a browser could choke so bad that it would 'die' 
over a small charset issue.   --John 

Comment 5

[timeless]

small,  heh. so, when you run mozilla from a screen session or a console (not a
console that lives in x11, a real one like ctrl-alt-f1), does it actually say it
crashed?

generally the fault lies with xft or your font server (and they in turn are the
things that tend to help knock off x11). there may be some stuff we can do about
this, but if it reaches the font server and that kills your xserver, it's out of
our hands and you should file bugs against someone else :).

Comment 6

[John McWade]

(In reply to comment #5)

>when you run mozilla from a screen session or a console...does it actually say
>it crashed?


Perhaps I shouldn't banter words so easily. To answer your question, when its
started from console the actual error (aside from my vague rendition) is:

Fatal server error:
Caught signal 11. Server aborting

***some stuff telling me where to find a log that says this exact same thing **

xinit: connection to X server lost.
xterm: fatal IO error 32 (Broken pipe) or KillClient on X server ":0.0"


(i wont assume a diagnosis here)

Comment 7

[Jungshik Shin]

The server doesn't emit charset. It just emits 'text/plain' so that it's your
default character encoding that may lead to this problem. (the page itself it is
in UTF-8 as found out earlier here.) I can't reproduce this bug with the default
char. encoding set to EUC-KR. I also tried ISO-8859-1 and a couple of other
single byte encoding, but my copy of 1.7.5 doesn't crash. (well, it's built
locally with 1.7.x branch source so that it's not exactly 1.7.5). Presumably,
the rpm is built with gtk2+xft. Just to be sure, what's the output of
'about:buildconfig'? Also, it'd help if you could give me your font pref.
setting for Western (or whatever 'langGroup' corresponding to your default
character encoding. for instance, if it's Windows-1252/ISO-8859-1, it's Western.
If it's WIndows-1251/KOI8-R, it's Cyrillic, etc)

Comment 8

[John McWade]

> Presumably, the rpm is built with gtk2+xft. Just to be sure, what's the output
>of 'about:buildconfig'? 

Output of about:buildconfig ...

target i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	   gcc version 3.2.3 	-Wall -W -Wno-unused -Wpointer-arith            
                                -Wcast-align -Wno-long-long -pedantic
-pthread -pipe c++ 	gcc version 3.2.3 	-fno-rtti -fno-exceptions -Wall
-Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic
-fshort-wchar -pthread -pipe -I/usr/X11R6/include

Configure arguments
--enable-application=suite --enable-extensions=default,irc,tasks,negotiateauth
--disable-tests --disable-debug '--enable-optimize=-O2 -gstabs+'
--without-system-nspr --without-system-zlib --without-system-jpeg
--without-system-png --without-system-mng --without-system-mng --enable-crypto 


> if you could give me your font pref.
> setting for Western (or whatever 'langGroup' corresponding to your default
> character encoding. for instance, if it's Windows-1252/ISO-8859-1, it's Western.
> If it's WIndows-1251/KOI8-R, it's Cyrillic, etc)

default encoding is set to iso-8859-1 in the preferences menu (western)

Comment 9

[Jungshik Shin]

(In reply to comment #8)

> Configure arguments
> --enable-application=suite --enable-extensions=default,irc,tasks,negotiateauth
> --disable-tests --disable-debug '--enable-optimize=-O2 -gstabs+'
> --without-system-nspr --without-system-zlib --without-system-jpeg
> --without-system-png --without-system-mng --without-system-mng --enable-crypto 

Hmm. it's not a gtk2+xft but an X11 corefont build. Then, I have to try to
reproduce again with Xft disabled. 
 

Comment 10

[Christopher Blizzard (:blizzard)]

Generally if you're crashing the X server it's an X server problem not a mozilla
problem.  Offensive clients shouldn't be able to crash the server.  That being
said, if we're doing something totally crazy we should probably avoid that
particular situation, especially since untrusted content can trigger it.

Comment 11

[Andrew Schultz]

dupe of "non-xft builds crash X server when viewing pages with unrecognized
unicode characters"

*** This bug has been marked as a duplicate of 244340 ***

Comment 12

[John McWade]

(In reply to comment #11)
> dupe of "non-xft builds crash X server when viewing pages with unrecognized
> unicode characters"
> 
> *** This bug has been marked as a duplicate of 244340 ***

well, if no one has any objections, i'd like to uninstall this from my box then