242327 - crash if using unicode characters with css [@ nsFT2FontNode::LoadNode ]

Status: RESOLVED EXPIRED

(Core Graveyard :: GFX: Gtk, defect)

Description

[Dietmar Rabich]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.6) Gecko/20040113

Mozilla crashes if a css file contains unicode.

For example:

div.Koerper a[href]:after
{
	content: "\25b7";
	vertical-align: top;
	padding-left: 0.2em;
	font-size: smaller;
}

If this CSS code ist used, Mozilla crashes. If it's changed to

div.Koerper a[href]:after
{
	content: ">";
	vertical-align: top;
	padding-left: 0.2em;
	font-size: smaller;
}

there is no crash.

The CSS code is includes with

<style type="text/css"><!--
@import url("common/style.css");
--></style>


Reproducible: Always
Steps to Reproduce:
1. Put the CSS source in a file
2. Include the file
3. Open the file (offline or online)
Actual Results:  
Mozilla crashes without comment.

Expected Results:  
;-) No crash.

I am using Linux with the new kernel 2.6. It's the new distribution SuSE 9.1.

Comment 1

[Dietmar Rabich]

I forgot the URL. Mozilla crashes for example if using this URL:
http://www.w3.org/Style/CSS/ .

Comment 2

[Dietmar Rabich]

Another information

In the page http://www.w3.org/Style/CSS/ it may be one of this CSS code parts in
the CSS file http://www.w3.org/Style/threepart.css :

span.date:after {
  content: "\A0\A0" }

div.banner a:after {
  content: " \2022";
  color: #900 }

div.banner a:before {
  content: "\2022  ";
  color: #900 }

Comment 3

[Bill Mason]

WFM 20040430 PC/WinXP

Comment 4

[Dietmar Rabich]

With my old OS (Linux Kernel 2.4, SuSE 9.0) I do not have any problems with the
sites.

The problem appears since I've updated to SuSE 9.1 (UTF-8 is now the default
character set) with Linux Version 2.6.4-52-default. Default encoding (in
germany) is now de_DE.UTF-8.

Comment 5

[Olivier Cahagne]

can you post a Talkback ID (using Firefox latest nightly build or Mozilla 1.7RC) ?
If not, please run mozilla in a a debugger:
"mozilla -g"
Once in GDB, start Mozilla with "GDB> run"
When Mozilla crashes, back in GDB, type "GDB> stacktrace" and attach the output
here (via "create a new attachment").

Comment 6

[Dietmar Rabich]

I had the same idea just a few minutes ago. Here are the results:

mozilla --debug:

The last lines:

--debug

[New Thread 1105935280 (LWP 4626)]
[New Thread 1108036528 (LWP 4627)]
[New Thread 1112542128 (LWP 4629)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1078972000 (LWP 4620)]
0x413edcf2 in NSGetModule () from /usr/local/mozilla/components/libgfx_gtk.so

And mozilla -g:

[New Thread 1105935280 (LWP 4706)]
[New Thread 1108036528 (LWP 4707)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1078972000 (LWP 4700)]
0x413edce7 in NSGetModule () from /usr/local/mozilla/components/libgfx_gtk.so

Comment 7

[Dietmar Rabich]

Attachment: stacktrace

The stacktrace.

(It's just the command "bt" (for backtrace) in gdb.)

Comment 8

[Boris Zbarsky [:bzbarsky]]

This is crashing somewhere in GFX land, not style system.  You may want to copy
the output of about:buildconfig into this bug so we know what font system your
build is using.

In any case, it sounds like your system has a buggy font or something along
those lines installed....

Also please do the talkback thing -- stack traces via gdb from stripped builds
(aka nightlies) are totally useless.

Comment 9

[tenthumbs]

I get seven of these

###!!! ASSERTION: garbled pattern: unexpected end of pattern: '*p', file
nsFT2FontNode.cpp, line 433
Break: at file nsFT2FontNode.cpp, line 433

on the w3 site with my gtk1 trunk build. Settign a breakpoint I see

Breakpoint 1, nsFT2FontNode::ParseXLFD (aPattern=0x8e59c20 "-*", aFoundry=0xa,
aFamily=0xbfffaef4, 
    aCharset=0xbfffaef8, aEncoding=0xbfffaefc) at nsFT2FontNode.cpp:433
433       NS_ASSERTION(*p,"garbled pattern: unexpected end of pattern");
(gdb) p p
$2 = 0x8e59c46 "*"

I'll attach a stack trace. It's actually from a break at line 429 but you get
the idea.

Comment 10

[tenthumbs]

Attachment: stack trace

Comment 11

[tenthumbs]

And I have no "Gill Sans *" font on my system.

Comment 12

[Dietmar Rabich]

Attachment: The result of about:buildconfig

You ask for the result of about:buildconfig. Here it is.

Comment 13

[Dietmar Rabich]

One more information. I've updated to Mozilla 1.7RC1. It crashes too.

But: First time I've started Mozilla 1.7RC1 everything is fine.

Then I've changed to preferences:

pref("font.FreeType2.enable", true);
pref("font.directory.truetype.1", "/usr/X11R6/lib/X11/fonts/truetype/");

Now Mozilla crashes again. Sometimes there are problems calling the dialogbox
for the font preferences too.

Talkback agent is active, so 2 reports are send. I don't know who will receive
the reports.

Comment 14

[Olivier Cahagne]

> pref("font.directory.truetype.1", "/usr/X11R6/lib/X11/fonts/truetype/");

Do you possibly have a font "gil*" (see comment 11) ?
 
> Talkback agent is active, so 2 reports are send. I don't know who will receive
> the reports.

Can you mention the Talkback IDs ? Run "components/talkback/talkback" to see the
TB IDs associated to the crashes for which you submitted Talkback report.

Comment 15

[Dietmar Rabich]

(In reply to comment #14)
> > pref("font.directory.truetype.1", "/usr/X11R6/lib/X11/fonts/truetype/");
> 
> Do you possibly have a font "gil*" (see comment 11) ?

I see, I have to learn more about Mozilla.

There are no fonts on my system with gil* or Gil* .

> > Talkback agent is active, so 2 reports are send. I don't know who will receive
> > the reports.
> 
> Can you mention the Talkback IDs ? Run "components/talkback/talkback" to see the
> TB IDs associated to the crashes for which you submitted Talkback report.

The talkback Id's (Incidents ID) are

- TB37172M
- TB37168H

Comment 16

[Olivier Cahagne]

Attachment: TB37168H data

Comment 17

[tenthumbs]

Forget what I said about the assertions. That's probably another bug unless you
have some weird font. It might be useful to run mozilla from an xterm like this:

 env NS_FONT_DEBUG=FFF mozilla 2>&1 |tee log

and see if anything interesting occurs. There'll be a lot of output but only the
part just before it crashes would be useful.

Comment 18

[Dietmar Rabich]

Attachment: Zipped file with logfile

Here is the output of the command

env NS_FONT_DEBUG=FFF mozilla 2>&1 |tee log

It's the whole output but only the site from W3C was called. 

And there are to new incidents with the following numbers:

TB39222Q
TB39228H

Thank you!

Comment 19

[Dietmar Rabich]

Please have a look to my last two incidents (TB39222Q, TB39228H). May be the 
incidient log (TB37168H) which is attached to this bug is another error. (A 
crash which dependence to font also true type font too, but not with the 
unicode characters used with CSS.)

Comment 20

[Olivier Cahagne]

these TB IDs all show the same stack, see http://talkback-public.mozilla.org/

Comment 21

[Thomas K. (:tom)]

http://spam.hixie.ch crashes mozilla and the default css appears to be the same
default as on his other pages.  switching to "orange" on other pages (such as
http://lh.hixie.ch) causes crashing.

don't know if author was referring to his spam.hixie.ch page doing this.

Comment 22

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 23

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.