737942 - Crash in gfxGDIFont::ShapeWord

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is 
report bp-e5c6460c-ff2c-4e3b-936d-dc9b42120321 .
============================================================= 

Seen while looking at Beta data - https://crash-stats.mozilla.com/report/list?signature=_chkstk%20|%20gfxGDIFont::ShapeWord%28gfxContext*,%20gfxShapedWord*,%20wchar_t%20const*,%20bool%29. Heaviest concentration of crash on Win XP.

Addon Correlations:

_chkstk | gfxGDIFont::ShapeWord(gfxContext*, gfxShapedWord*, wchar_t const*, bool)|EXCEPTION_ACCESS_VIOLATION_READ (51 crashes)
     18% (9/51) vs.  10% (2088/21798) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865)
     16% (8/51) vs.   9% (1989/21798) [e-mail] (Java Quick Starter, http://java.sun.com/javase/downloads/)
     82% (42/51) vs.  77% (16751/21798) [e-mail] (Mozilla Labs - Test Pilot, https://addons.mozilla.org/addon/13661)
      6% (3/51) vs.   1% (141/21798) {a3a5c777-f583-4fef-9380-ab4add1bc2a8}
      6% (3/51) vs.   1% (142/21798) {0538E3E3-7E9B-4d49-8831-A227C80A7AD3} (Forecastfox, https://addons.mozilla.org/addon/398)

Module:

_chkstk | gfxGDIFont::ShapeWord(gfxContext*, gfxShapedWord*, wchar_t const*, bool)|EXCEPTION_ACCESS_VIOLATION_READ (51 crashes)
     78% (40/51) vs.  35% (7703/21798) cryptui.dll
    100% (51/51) vs.  57% (12412/21798) t2embed.dll
     78% (40/51) vs.  40% (8694/21798) lz32.dll
    100% (51/51) vs.  62% (13555/21798) shdocvw.dll
     78% (40/51) vs.  41% (8949/21798) wldap32.dll
     86% (44/51) vs.  49% (10719/21798) mpr.dll
     78% (40/51) vs.  42% (9214/21798) xpsp2res.dll
    100% (51/51) vs.  64% (14019/21798) nssckbi.dll
    100% (51/51) vs.  65% (14172/21798) freebl3.dll
    100% (51/51) vs.  65% (14173/21798) nssdbm3.dll
     78% (40/51) vs.  44% (9686/21798) iphlpapi.dll
    100% (51/51) vs.  67% (14690/21798) feclient.dll
    100% (51/51) vs.  70% (15234/21798) winrnr.dll
     78% (40/51) vs.  49% (10595/21798) hnetcfg.dll
     78% (40/51) vs.  49% (10681/21798) wshtcpip.dll
    100% (51/51) vs.  71% (15478/21798) browsercomps.dll
     84% (43/51) vs.  57% (12485/21798) netapi32.dll
    100% (51/51) vs.  73% (16014/21798) softokn3.dll
    100% (51/51) vs.  74% (16024/21798) firefox.exe
    100% (51/51) vs.  74% (16057/21798) xpcom.dll
    100% (51/51) vs.  74% (16212/21798) dbghelp.dll
    100% (51/51) vs.  75% (16240/21798) rasadhlp.dll
     57% (29/51) vs.  33% (7191/21798) MSCTF.dll
     84% (43/51) vs.  61% (13213/21798) imagehlp.dll
     84% (43/51) vs.  61% (13268/21798) winspool.drv
     78% (40/51) vs.  55% (12043/21798) comres.dll
    100% (51/51) vs.  77% (16780/21798) dnsapi.dll
     78% (40/51) vs.  56% (12277/21798) ws2help.dll
     43% (22/51) vs.  21% (4651/21798) MSCTFIME.IME
     86% (44/51) vs.  68% (14750/21798) rsaenh.dll
    100% (51/51) vs.  86% (18761/21798) wintrust.dll
    100% (51/51) vs.  87% (19018/21798) mswsock.dll
     37% (19/51) vs.  25% (5420/21798) samlib.dll
    100% (51/51) vs.  88% (19270/21798) setupapi.dll
     12% (6/51) vs.   2% (540/21798) RocketDock.dll
    100% (51/51) vs.  91% (19901/21798) mscms.dll
     18% (9/51) vs.  10% (2120/21798) atl.dll
    100% (51/51) vs.  92% (20138/21798) userenv.dll
     65% (33/51) vs.  57% (12492/21798) normaliz.dll
     16% (8/51) vs.   9% (1916/21798) idmmkb.dll
     31% (16/51) vs.  25% (5346/21798) d3d8thk.dll
     31% (16/51) vs.  25% (5370/21798) d3d9.dll
     14% (7/51) vs.   8% (1673/21798) actxprxy.dll
    100% (51/51) vs.  94% (20596/21798) crypt32.dll
    100% (51/51) vs.  95% (20603/21798) msasn1.dll
     24% (12/51) vs.  18% (4012/21798) mdnsNSP.dll
     61% (31/51) vs.  56% (12140/21798) midimap.dll
     61% (31/51) vs.  56% (12149/21798) msacm32.drv

Comment 1

[Alex Keybl [:akeybl]]

Is this nominated for tracking because we're sure that this is a recent regression? Or do we suspect this will become a top crasher?

Comment 2

[Jonathan Kew [:jfkthame]]

This looks like it's essentially the same underlying issue as bug 732925, which looks like a stack overflow when attempting to lay out a run of text. Bug 703100 moved the text-shaping process from gfxGDIFont::InitTextRun to gfxGDIFont::ShapeWord, which explains why the Firefox 11 and 12 crashes show different stacks.

Comment 3

[Marcia Knous [:marcia]]

Nominated because it appeared to be a new signature/regression that was hitting Win XP users which is a large user base.  

(In reply to Alex Keybl [:akeybl] from comment #1)
> Is this nominated for tracking because we're sure that this is a recent
> regression? Or do we suspect this will become a top crasher?

Comment 4

[Scoobidiver (away)]

(In reply to Marcia Knous [:marcia] from comment #3)
> Nominated because it appeared to be a new signature/regression that was
> hitting Win XP users which is a large user base.  
Bug 732925 is #29 top browser crasher in 11.0 and this bug is #36 in 12.0b1, so there's nothing new in 12.0.

Comment 5

[Jonathan Kew [:jfkthame]]

bsmedberg, this is very much the same scenario as bug 732925 - it's a different stack on FF12 because the text-shaping code has been refactored, but the same issue of crashing in _chkstk with an access violation at 0x10f000 (on WinXP), when we need a 20K stack frame for harfbuzz shaping. Any suggestions?

Comment 6

[Alex Keybl [:akeybl]]

Not sure you're the right assignee here bsmedberg, but since this is tracked for FF12 I'm going to push this your way with a next action of answering Comment 5.

Comment 7

[Benjamin Smedberg]

In the minidump from comment 0, at the time of the crash:

$ESP	0x00112060
$EAX	0x0010f000 (also the crashing address)
XRE_main's return address is at 0x0012f108

So the actual stack size is 0x20108 or 131336 bytes. So we're still nowhere near exhausting stack space. I don't know why this is happening.

Comment 8

[Sheila Mooney]

This is not very high volume. I removed the top crash keyword. Should this be duped to the other bug? I removed the tracking flag as well.

Comment 9

[Benjamin Smedberg]

I am not working on this.

Comment 10

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

Mass resolving WFM: signature(s) hasn't(/haven't) reported in past 28 days.