Closed Bug 220582 Opened 21 years ago Closed 21 years ago

[xft] Browser crashes when rendering control characters in C0

Categories

(Core Graveyard :: GFX: Gtk, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 213734

People

(Reporter: nikarul, Assigned: blizzard)

References

()

Details

(Keywords: crash, testcase)

Attachments

(2 files)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030923 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030923 The browser crashes when trying to load the file above, either locally or remotely. It appears to be a problem with one of the non-printable characters at either the beginning or end of the file, as the browser no longer crashes without those lines. Reproducible: Always Steps to Reproduce: 1. Open up mozilla, and go to the given address Actual Results: The browser will crash before loading the file. Expected Results: Loaded the text file.
Are you using an xft build? You can type "about:buildconfig" in the URL bar and hit enter to find out... I cannot reproduce the crash with a non-xft Mozilla nightly from Sept 24...
It appears so. Here is the output of my about:buildconfig. about:buildconfig Build platform target i686-pc-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 3.3.1 20030904 (Gentoo Linux 3.3.1-r1, propolice) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -march=athlon-xp -pipe -s -fforce-addr -pthread -pipe g++ gcc version 3.3.1 20030904 (Gentoo Linux 3.3.1-r1, propolice) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long -march=athlon-xp -pipe -s -fforce-addr -Wno-deprecated -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --prefix=/usr/lib/mozilla --disable-pedantic --disable-short-wchar --disable-xprint --enable-mathml --without-system-nspr --enable-nspr-autoconf --with-system-zlib --enable-xsl --enable-crypto --enable-extensions=default --enable-optimize=-O2 --with-default-mozilla-five-home=/usr/lib/mozilla --enable-toolkit-gtk --enable-default-toolkit=gtk --disable-toolkit-qt --disable-toolkit-xlib --disable-toolkit-gtk2 --disable-ldap --enable-strip-libs --disable-debug --disable-tests --enable-reorder --enable-strip --enable-elf-dynstr-gc --enable-xft --disable-freetype2 --disable-svg --enable-old-abi-compat-wrappers
To blizzard.
Assignee: general → blizzard
Severity: normal → critical
Component: Browser-General → GFX: Gtk
Keywords: crash
QA Contact: general → ian
Summary: Browser crashes when trying to load the given file → [xft] Browser crashes when trying to load the given file
Attached file stacktrace (deleted) —
this is from CVS/xft/gtk2 trunk about a week old.
Attached file testcase (deleted) —
^[]1;^G^[]2;Started emerge on: Sep 28, 2003 ^[ and ^G are control characters.
before crashing, valgrind says: Invalid read of size 4 XftDrawGlyphFontSpec (in /usr/X11R6/lib/libXft.so.2.1) nsFontMetricsXft::DrawString() (nsFontMetricsXft.cpp:724) nsRenderingContextGTK::DrawString() (nsRenderingContextGTK.cpp:1310) nsTextFrame::PaintAsciiText() (nsTextFrame.cpp:3210) I'm running Xft from RH9's XFree86-4.3.0-2 marking NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: xft_tracking
Keywords: testcase
Works for me. My build is a bit old (I haven't updated my tree for about a week), but the last time nsFontMetricsXft.cpp was changed was Sep. 13 so that it shouldn't matter. It could be font-dependent. I have Bistream Vera fonts which seem to have some visible glyphs for characters in C0 (like U+0007 :CTRL-G and U+001B:ESC). Alternatively, it could be libXft. My libXft was built from the CVS source(http://fontconfig.org) in early September. Can you see if installing libXft from the CVS snapshot makes any difference? Another to try is adding U+0000 to U+001F to the blank character list /etc/fonts/font.conf. (I don't have them in the list and Mozilla still doesn't crash). BTW, fixing bug 209081 for Xft build should fix this in any case.
Summary: [xft] Browser crashes when trying to load the given file → [xft] Browser crashes when rendering control characters in C0
sorry for spamming. it's bug 205387
Andrew, if you built a debug build, can you try run your debug build with the environment variable NSPR_LOG_MODULES set to XftFontLoad:5 and see which font is selected before Moizlla crashes? I can't reproduce the crash on my machine probably because I have a font with visible glyphs for the control characters. (I finally got my own machine back with fresh RH 9 installed. I haven't installed libXft from the fontconfig CVS, yet , on this machine).
the last thing before the crash was this: [0x865cc88] setting up pattern with the following specification: lang group: x-western adding generic family: monospace point,pixel size: 9,180 slant: roman weight: (orig,calc) 400,100 matched the following (16) fonts: Luxi Mono Nimbus Mono L Nimbus Mono L Courier Nimbus Roman No9 L Nimbus Sans L Computer Modern LucidaTypewriter MiscFixed MiscFixed MiscFixed console8x16 MiscFixed MiscFixed Standard Symbols L Computer Modern it appears to be just trying to use a normal monospace font.
Thanks. That helps although it's a bit tedious to go through all 16 of them ( I wish there were fewer matches :-)) with a font viewer/editor to see what's wrong (one of them may claim that they have glyphs for C0 characters, but actually what it has for them may trigger this bug possibly in libXft).
Looks like a dup. *** This bug has been marked as a duplicate of 213734 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: