Closed Bug 605347 Opened 14 years ago Closed 14 years ago

@font-face SIGFPE crash with Google Web Font directory in libpangooft2 [@ libpangoft2-1.0.so.0.2800.1@0x1c6c8 ]

Categories

(Core :: Graphics, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: me, Assigned: karlt)

References

()

Details

(Keywords: crash, Whiteboard: [fixed by bug 569770])

Crash Data

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101012 Firefox-4.0/4.0b8pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101012 Firefox-4.0/4.0b8pre

Loading the Google Web Font directory in Firefox 4 in Linux, the page starts loading the fonts and then the browser crashes.

Reproducible: Always

Steps to Reproduce:
1. Use Firefox 4 in Linux
2. Load http://code.google.com/webfonts
Actual Results:  
Crash.

Expected Results:  
Not crash.

Talkback crash ID: 766d4e60-bcb7-4c6c-b168-d9c062101018

http://crash-stats.mozilla.com/report/index/766d4e60-bcb7-4c6c-b168-d9c062101018

Seems to be experienced by a number of people.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Summary: @font-face crash with Google Web Font directory in libpangooft2 → @font-face crash with Google Web Font directory in libpangooft2 [@ libpangoft2-1.0.so.0.2800.1@0x1c6c8 ]
Version: unspecified → Trunk
blocking2.0: --- → ?
Component: Graphics → Layout: Text
QA Contact: thebes → layout.fonts-and-text
Pango integration code lives in gfx, switching back to gfx.
Component: Layout: Text → Graphics
QA Contact: layout.fonts-and-text → thebes
Depends on: 569770
Summary: @font-face crash with Google Web Font directory in libpangooft2 [@ libpangoft2-1.0.so.0.2800.1@0x1c6c8 ] → @font-face SIGFPE crash with Google Web Font directory in libpangooft2 [@ libpangoft2-1.0.so.0.2800.1@0x1c6c8 ]
Here, with Firefox 3.6.9, it appears as a hang, as if our fpehandler is trying to continue after the exceptions.  (I don't have crashreporter enabled.)

#0  fpehandler (signum=8, si=0x7fff3d0a0f30, context=0x7fff3d0a0e00)
    at nsSigHandlers.cpp:256
#1  <signal handler called>
#2  0x00007fe31280e1c3 in _hb_sanitize_array (this=0x40de5cc, 
    context=0x7fff3d0a13c0) at hb-open-type-private.hh:213
#3  PairPosFormat2::sanitize (this=0x40de5cc, context=0x7fff3d0a13c0)
    at hb-ot-layout-gpos-private.hh:711
#4  PairPos::sanitize (this=0x40de5cc, context=0x7fff3d0a13c0)
    at hb-ot-layout-gpos-private.hh:765
#5  0x00007fe31280fa0c in GenericOffsetTo<USHORT, PosLookupSubTable>::sanitize (
    this=<value optimized out>, context=0x7fff3d0a13c0)
    at hb-open-type-private.hh:479
#6  GenericArrayOf<USHORT, OffsetTo<PosLookupSubTable> >::sanitize (
    this=<value optimized out>, context=0x7fff3d0a13c0)
    at hb-open-type-private.hh:550
#7  PosLookup::sanitize (this=<value optimized out>, context=0x7fff3d0a13c0)
    at hb-ot-layout-gpos-private.hh:1538
#8  GenericOffsetTo<USHORT, PosLookup>::sanitize (this=<value optimized out>, 
    context=0x7fff3d0a13c0) at hb-open-type-private.hh:465
#9  GenericArrayOf<USHORT, OffsetTo<PosLookup> >::sanitize (
    this=<value optimized out>, context=0x7fff3d0a13c0)
    at hb-open-type-private.hh:532
#10 OffsetListOf<PosLookup>::sanitize (this=<value optimized out>, 
    context=0x7fff3d0a13c0) at hb-open-type-private.hh:591
#11 GenericOffsetTo<USHORT, OffsetListOf<PosLookup> >::sanitize (
    this=<value optimized out>, context=0x7fff3d0a13c0)
    at hb-open-type-private.hh:465
#12 GPOS::sanitize (this=<value optimized out>, context=0x7fff3d0a13c0)
    at hb-ot-layout-gpos-private.hh:1569
#13 0x00007fe3128055ce in Sanitizer<GPOS>::sanitize (face=0x30fb090)
    at hb-open-type-private.hh:279
#14 _hb_ot_layout_init (face=0x30fb090) at hb-ot-layout.cc:55
#15 0x00007fe312801c2d in hb_face_create_for_data (blob=<value optimized out>, 
    index=<value optimized out>) at hb-font.cc:182
#16 0x00007fe3127ff21d in pango_ot_info_get (face=0x4107190)
    at pango-ot-info.c:154
#17 0x00007fe2f0cc1549 in basic_engine_shape (engine=<value optimized out>, 
    font=<value optimized out>, text=<value optimized out>, 
    length=<value optimized out>, analysis=<value optimized out>, 
    glyphs=<value optimized out>) at basic-fc.c:209
#18 0x00007fe3125d21dd in pango_shape (text=0x7fff3d0a17e3 "Philosopher", 
    length=11, analysis=0x40a6db0, glyphs=0x3f5eba0) at shape.c:55
#19 0x00007fe316a1e022 in gfxPangoFontGroup::CreateGlyphRunsItemizing (
    this=0x3f265d0, aTextRun=<value optimized out>, 
    aUTF8=<value optimized out>, aUTF8Length=<value optimized out>, 
    aUTF8HeaderLen=<value optimized out>) at gfxPangoFonts.cpp:3088
#20 0x00007fe316a1ee8c in gfxPangoFontGroup::MakeTextRun (this=0x3f265d0, 
    aString=<value optimized out>, aLength=<value optimized out>, 
    aParams=<value optimized out>, aFlags=<value optimized out>)
    at gfxPangoFonts.cpp:2373
#21 0x00007fe316a18d37 in TextRunWordCache::MakeTextRun (
    this=<value optimized out>, aText=<value optimized out>, 
    aLength=<value optimized out>, aFontGroup=0x3f265d0, 
    aParams=0x7fff3d0a3370, aFlags=<value optimized out>)
    at gfxTextRunWordCache.cpp:811

Works fine in my m-c build including patches for bug 569770, which doesn't use this path for the scripts on this page.
Assignee: nobody → karlt
blocking2.0: ? → final+
Blocks: 604380
I fixed this in pango and it's in the latest releases, but apparently not all distros have picked it up.

Can you guys make your fpehandler more lenient?
(In reply to comment #2)
> Here, with Firefox 3.6.9, it appears as a hang, as if our fpehandler is trying
> to continue after the exceptions.  (I don't have crashreporter enabled.)

That's because we don't have bug 538338 fixed on 1.9.2.
But, with release builds, I get the crashreporter anyway.
(In reply to comment #3)
> I fixed this in pango and it's in the latest releases, but apparently not all
> distros have picked it up.
> 
> Can you guys make your fpehandler more lenient?

Thanks, Behdad for
http://git.gnome.org/browse/pango/commit/?id=152e0aab5bb29d691e5e69e2f375b3b42e15e48e
(which is also in 1.28.2).

I'm not sure that we want to pick any sort of result for integer divide by zero.
I think it's probably safer from a security perspective to abort than to continue with an inappropriate integer result for an unknown purpose.
Bug 569770 has now landed.  I can't reproduce now even with 3.6.12, so I suspect the Philosopher font may have been updated.  The font says it was last modified 2010-09-10 16:08:43 UTC.

The http response header for
http://themes.googleusercontent.com/font?kit=OttjxgcoEsufOGSINYBGLWeudeTO44zf-ht3k-KNzwg says it was last modified:
Thu, 04 Nov 2010 18:05:56 GMT
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 569770]
Crash Signature: [@ libpangoft2-1.0.so.0.2800.1@0x1c6c8 ]
You need to log in before you can comment on or make changes to this bug.