Closed Bug 213734 Opened 21 years ago Closed 21 years ago

Browser crashes when loading URL [@ XftDrawGlyphFontSpec ][@ nsFontMetricsXft::DrawString ]

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla-mozilla, Assigned: blizzard)

References

(
URL
)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file, 1 obsolete file)

make sure to use the real size of the buffer, not the full len of the string
614 bytes, patch
jshin1987
: review+
dbaron
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030721 Debian/1.4-2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030721 Debian/1.4-2

Everytime I load the URL
http://4c.ucc.ie/~cbosch/mozcrash.txt the browser crashes.

It is generated on linux by doing:
watch -n 1 echo "You can\'t 
seriously be suggesting a textfile can crash Mozilla - can 
you?" | tee public_html/mozcrash.txt

Reproducible: Always

Steps to Reproduce:
1.Load the URL
2.
3.

Actual Results:  
browser crashed

Expected Results:  
displayed it

I've asked around and to date I've found:
it doesn't seem to crash windows clients
it doesn't seem to crash older linux builds (1.2.1)
it crashes Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) 
Gecko/20030715 Mozilla Firebird/0.6  on a Redhat 9 box

this also crashes the same browsers: http://4c.ucc.ie/~cbosch/mozc2.txt
Setting appropriate severity/keyword.
Severity: normal → critical
Keywords: crash
Before I forget.. I just removed the mozilla-xft support, and it doesn't crash.
Looks horrible, but renders the files properly. 
wfm using build 2003072405 on Linux (Mandrake 9.1).
Probably a font issue, are you running XFT or GTK2 build ? Can you post a
Talkback ID for this crash (components/talkback/) or GDB stack trace ?
do you have and .fon font files in your font directory ?
Keywords: stackwanted
Blocks: xft_triage
#0  0x406a1b56 in XftDrawGlyphFontSpec () from /usr/X11R6/lib/libXft.so.2
#1  0x412cb853 in nsFontMetricsXft::DrawString(char const*, unsigned, int, int,
int const*, nsRenderingContextGTK*, nsDrawingSurfaceGTK*) () from
/usr/lib/mozilla/components/libgfx_gtk.so
#2  0x412adb6b in nsRenderingContextGTK::DrawString(char const*, unsigned, int,
int, int const*) () from /usr/lib/mozilla/components/libgfx_gtk.so
#3  0x40b5c7cb in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#4  0x40b590a5 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#5  0x40b0fad6 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#6  0x40b08884 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#7  0x40b21a86 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#8  0x40b0869a in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#9  0x40b0fad6 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#10 0x40b08884 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#11 0x40b21a86 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#12 0x40b0869a in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#13 0x40b0fad6 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#14 0x40b08884 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#15 0x40b21a86 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#16 0x40b0869a in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#17 0x40b0fad6 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#18 0x40b0f9ce in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#19 0x40b219f6 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#20 0x40b22ca9 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#21 0x40b506de in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#22 0x40e3c0a1 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#23 0x40e41af5 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#24 0x40e4193e in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#25 0x40e402bf in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#26 0x40e42e7b in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#27 0x40e3b8bc in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
#28 0x410cc9da in nsCommonWidget::DispatchEvent(nsGUIEvent*, nsEventStatus&) ()
   from /usr/lib/mozilla/components/libwidget_gtk2.so
#29 0x410c4d11 in nsWindow::OnExposeEvent(_GtkWidget*, _GdkEventExpose*) ()
   from /usr/lib/mozilla/components/libwidget_gtk2.so
#30 0x410c8e49 in nsWindow::HideWindowChrome(int) ()
   from /usr/lib/mozilla/components/libwidget_gtk2.so
#31 0x401d2519 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0
#32 0x40410872 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#33 0x4041ff46 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#34 0x4041ef05 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#35 0x4041f2e3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#36 0x4028e903 in gtk_widget_send_expose () from /usr/lib/libgtk-x11-2.0.so.0
#37 0x401d139b in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#38 0x4034e542 in gdk_window_clear_area_e () from /usr/lib/libgdk-x11-2.0.so.0
#39 0x4034e5e2 in gdk_window_process_all_updates () from
/usr/lib/libgdk-x11-2.0.so.0
#40 0x4034e646 in gdk_window_process_all_updates () from
/usr/lib/libgdk-x11-2.0.so.0
#41 0x4045c918 in g_timeout_add () from /usr/lib/libglib-2.0.so.0
#42 0x4045a1bb in unblock_source () from /usr/lib/libglib-2.0.so.0
#43 0x4045b0ad in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#44 0x4045b3af in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#45 0x4045b9de in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#46 0x401d0c97 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#47 0x410cb19c in nsAppShell::Run() () from
/usr/lib/mozilla/components/libwidget_gtk2.so
#48 0x4109ecb6 in NSGetModule () from /usr/lib/mozilla/components/libnsappshell.so
#49 0x08057b6a in getCountry(nsAString const&, nsAString&) ()
#50 0x08058340 in main ()
#51 0x4057ea51 in __libc_start_main () from /lib/libc.so.6

I can't see any .fon files in any of my font directories.

Font setup is currently:
Proportional: Serif
Serif: Serif
Sans-serif: sans-serif
Cursive: serif
Fantasy: serif
Monospace: monospace

(I can't see which fonts those are aliases to, but looking at XftConfig, I think
it's serif is Times, and sans is Helvetica). I have the Microsoft Web TrueType
fotns installed, and also the Gnome Bitstream Vera.
Keywords: stackwanted
Summary: Browser crashes when loading URL → Browser crashes when loading URL [@ XftDrawGlyphFontSpec ][@ nsFontMetricsXft::DrawString ]
-> blizzard for XFT
Assignee: general → blizzard
WFM todays FB - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030724
Mozilla Firebird/0.6
don´t know if it matters, but the text isn´t pure text, it starts with escape
sequences and contains lots of them.

Start of file, in hex, and written like in Printer Manuals:

1b 28 42       = ESC ( B
1b 29 30       = ESC ) 0
1b 5b 3f       = ESC [ ?
31 30 34 38 68 = 1 0 4 8 h 
1b 5b 3f       = ESC [ ?
31 30 34 37 68 = 1 0 4 7 h 
probably a dupe of bug 173204
It would seem it's not *purely* related to presence of escape sequences; try the
various mozc?.txt linked from http://4c.ucc.ie/~cbosch/crashes.html - it would
seem that the amount of text after an escape sequence is significant, suggesting
a buffer overflow.

*sigh* this is what I get for trying to use a tee within a watch...
Liam, can you specify the version of your Xfree86? I encounter the same bug on
Xfree86-4.3.0-47. But using Mozilla1.4(Xft+Gtk2 build) on RedHat9.0, which uses
Xfree86-4.3.0-2, I can't reproduce this bug. I suspect the new version of
XftDrawGlyphFontSpec in Xfree86-4.3.0-47 has problem.
Apologies for the delay..

X is 4.3.0 from libranet: 4.3.0-0ds2lbedford@marmite:~$ X -version

XFree86 Version 4.3.0 (Debian 4.3.0-0ds2 20030304042836 dstone@aedificator)
Release Date: 27 February 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.21-pre5 i686 [ELF] 
Build Date: 04 March 2003
        Before reporting problems, check http://www.XFree86.Org/
        to make sure that you have the latest version.
Module Loader present
OS Kernel: Linux version 2.6.0-test4 (root@marmite) (gcc version 3.3.1 20030626
(Debian prerelease)) #2 Mon Aug 25 11:37:14 IST 2003
Currently, it is because mozilla sent to XftDrawGlyphFontSpec with some
data contains NULL pointers. Just let XftDrawGlyphFontSpec check for the NULL
pointer and ignore it will fix this bug.
    Of cause, mozilla should fix itself to not send NULL pointered data in the
future to completely fix this bug.
Keith will probably be interested in this.  So will owen.
*** Bug 220582 has been marked as a duplicate of this bug. ***
I don't think Xft should try and guess what NULL means in this context; if Moz
can't find a font to display a particular glyph, it should either just use the
first font in it's list (to get the default glyph) or elide the glyph from the
array.

Can someone figure out *why* mozilla is failing to find a suitable font in this
case?
Hmm.  I can't reproduce this here anymore.  Most of the test cases are 404s now.
404's fixed. My apologies.
Blocks: xft_tracking
No longer blocks: xft_triage
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
If we happen to stumble across unknown glyphs in an ascii string (yes, it can
apparently happen) we need to use the actual size of the spec buffer, not the
full len of the string.
Attachment #132288 - Attachment is obsolete: true
Attachment #133871 - Flags: review?(jshin)
Can others test this patch as well?
I have tested the patch against Mozilla 1.4 (on SuSE). All the testcases won't
crash anymore.
Comment on attachment 133871 [details] [diff] [review]
make sure to use the real size of the buffer, not the full len of the string

r=jshin

Sorry it's late. I have to check my bugmail setting...

BTW, porting the fix for bug 205387  to Xft would have solved the problem as
well (for C0 characters). Still, using the actual spec buffer length is a good
defense (for who-knows-why faulty fonts with 'empty' glyphs for 'visibile AsCII
chars').
Attachment #133871 - Flags: review?(jshin) → review+
Attachment #133871 - Flags: superreview?(dbaron)
Attachment #133871 - Flags: superreview?(dbaron) → superreview+
Checked in.  Thanks!
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 217963 has been marked as a duplicate of this bug. ***
*** Bug 199049 has been marked as a duplicate of this bug. ***
Alas, testcase URL still crash my freshly built GTK2/Xft Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.6b) Gecko/20031208 (also see duplicated bug 199049 for
another crash testcase and backtrace).

Just updated to latest trunk, now mozilla --sync hangs on testcase URL.
Attaching gdb shows following backtrace:

#0  0x420e187e in select () from /lib/i686/libc.so.6
#1  0x40554d44 in _XlcPublicMethods () from /usr/X11R6/lib/libX11.so.6
#2  0x404b245a in _XRead () from /usr/X11R6/lib/libX11.so.6
#3  0x404b2f1a in _XReply () from /usr/X11R6/lib/libX11.so.6
#4  0x404ae7e8 in XSync () from /usr/X11R6/lib/libX11.so.6
#5  0x404ae881 in _XSyncFunction () from /usr/X11R6/lib/libX11.so.6
#6  0x4044ca9d in XRenderCompositeText8 () from /usr/X11R6/lib/libXrender.so.1
#7  0x403d7102 in XftGlyphFontSpecRender () from /usr/lib/libXft.so.2
#8  0x403d1e74 in XftDrawGlyphFontSpec () from /usr/lib/libXft.so.2
#9  0x40fb4e35 in NSGetModule ()
   from /home/mike/mozilla/components/libgfx_gtk.so
....

I'm using Xft-2.2-0.ximian.4.5.


*** Bug 229174 has been marked as a duplicate of this bug. ***
*** Bug 212653 has been marked as a duplicate of this bug. ***
*** Bug 225489 has been marked as a duplicate of this bug. ***
*** Bug 234662 has been marked as a duplicate of this bug. ***
*** Bug 235183 has been marked as a duplicate of this bug. ***
*** Bug 234558 has been marked as a duplicate of this bug. ***
Blocks: 240409
Product: Browser → Seamonkey
Status: RESOLVED → VERIFIED
Crash Signature: [@ XftDrawGlyphFontSpec ] [@ nsFontMetricsXft::DrawString ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: