630201 - Crash [@ nsTArray<DWRITE_GLYPH_OFFSET, nsTArrayDefaultAllocator>::Clear() ] with pre-Windows-RTM versions

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Scoobidiver (away)]

It is a new crash signature. Crashes first appeared in 4.0b10pre/20110121153543 and are discontinuous according to builds.
It is #27 top crasher in 4.0b11pre over the last week (#10 top crasher in yesterday's build).

Signature	nsTArray<DWRITE_GLYPH_OFFSET, nsTArrayDefaultAllocator>::Clear()
UUID	65d31297-9f58-4d6e-9768-bee312110131
Time 	2011-01-31 00:00:14.987384
Uptime	298
Last Crash	312 seconds (5.2 minutes) before submission
Install Age	59169 seconds (16.4 hours) since version was first installed.
Product	Firefox
Version	4.0b11pre
Build ID	20110130030342
Branch	2.0
OS	Windows NT
OS Version	6.1.7100
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 13
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x6874f0ca
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0402, AdapterDriverVersion: 8.17.12.6658

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsTArray<DWRITE_GLYPH_OFFSET,nsTArrayDefaultAllocator>::Clear 	obj-firefox/dist/include/nsTArray.h:845
1 	xul.dll 	nsTArray<nsBlinkTimer::FrameData,nsTArrayDefaultAllocator>::~nsTArray<nsBlinkTimer::FrameData,nsTArrayDefaultAllocator> 	obj-firefox/dist/include/nsTArray.h:373
2 	xul.dll 	gfxDWriteShaper::InitTextRun 	gfx/thebes/gfxDWriteShaper.cpp:224
3 	xul.dll 	gfxFont::InitTextRun 	gfx/thebes/gfxFont.cpp:1556
4 	xul.dll 	gfxFont::SplitAndInitTextRun 	gfx/thebes/gfxFont.cpp:1518
5 	xul.dll 	gfxFontGroup::InitScriptRun 	gfx/thebes/gfxFont.cpp:2477
6 	xul.dll 	gfxFontGroup::InitTextRun 	gfx/thebes/gfxFont.cpp:2442
7 	xul.dll 	gfxFontGroup::MakeTextRun 	gfx/thebes/gfxFont.cpp:2394
8 	xul.dll 	TextRunWordCache::MakeTextRun 	gfx/thebes/gfxTextRunWordCache.cpp:726
9 	xul.dll 	MakeTextRun 	layout/generic/nsTextFrameThebes.cpp:508
10 	xul.dll 	BuildTextRunsScanner::BuildTextRunForFrames 	layout/generic/nsTextFrameThebes.cpp:1878
11 	xul.dll 	BuildTextRunsScanner::FlushFrames 	layout/generic/nsTextFrameThebes.cpp:1304
12 	xul.dll 	BuildTextRuns 	layout/generic/nsTextFrameThebes.cpp:1235
13 	xul.dll 	nsTextFrame::EnsureTextRun 	layout/generic/nsTextFrameThebes.cpp:2154
14 	xul.dll 	nsTextFrame::AddInlineMinWidthForFlow 	layout/generic/nsTextFrameThebes.cpp:5990
15 	xul.dll 	nsTextFrame::AddInlineMinWidth 	layout/generic/nsTextFrameThebes.cpp:6102
16 	xul.dll 	nsBlockFrame::GetMinWidth 	layout/generic/nsBlockFrame.cpp:762
17 	xul.dll 	nsLayoutUtils::IntrinsicForContainer 	layout/base/nsLayoutUtils.cpp:2138
18 	xul.dll 	nsBlockFrame::GetMinWidth 	layout/generic/nsBlockFrame.cpp:743
19 	xul.dll 	nsListControlFrame::GetMinWidth 	layout/forms/nsListControlFrame.cpp:518
20 	xul.dll 	nsComboboxControlFrame::GetIntrinsicWidth 	layout/forms/nsComboboxControlFrame.cpp:564
21 	xul.dll 	nsComboboxControlFrame::GetMinWidth 	layout/forms/nsComboboxControlFrame.cpp:589
22 	xul.dll 	nsContainerFrame::ComputeAutoSize 	layout/generic/nsContainerFrame.cpp:693
23 	xul.dll 	nsFrame::ComputeSize 	layout/generic/nsFrame.cpp:3341
24 	xul.dll 	nsHTMLReflowState::InitConstraints 	layout/generic/nsHTMLReflowState.cpp:1849
25 	xul.dll 	nsComboboxControlFrame::IsFrameOfType 	layout/forms/nsComboboxControlFrame.h:137
26 	xul.dll 	nsHTMLReflowState::nsHTMLReflowState 	layout/generic/nsHTMLReflowState.cpp:177
27 	xul.dll 	nsLineLayout::ReflowFrame 	layout/generic/nsLineLayout.cpp:802
28 	xul.dll 	nsBlockFrame::ReflowInlineFrame 	layout/generic/nsBlockFrame.cpp:3811
29 	xul.dll 	nsBlockFrame::DoReflowInlineFrames 	layout/generic/nsBlockFrame.cpp:3607
30 	xul.dll 	nsBlockFrame::ReflowInlineFrames 	layout/generic/nsBlockFrame.cpp:3466
...

More reports at:
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsTArray%3CDWRITE_GLYPH_OFFSET%2C%20nsTArrayDefaultAllocator%3E%3A%3AClear%28%29

Comment 1

[Joe Drew (not getting mail)]

Scoobidiver, will you keep an eye on this and, should this pop up as very bad, renominate for 2.0?

Comment 2

[Scoobidiver (away)]

Due to a patch in Socorro, its signature changed to:
nsTArray<nsColInfo, nsTArrayDefaultAllocator>::Clear() | nsTArray<DWRITE_GLYPH_OFFSET, nsTArrayDefaultAllocator>::~nsTArray<DWRITE_GLYPH_OFFSET, nsTArrayDefaultAllocator>() | gfxDWriteShaper::InitTextRun(gfxContext*, gfxTextRun*, unsigned short const*,... 
It is too long for the bug summary!

It is #11 top crasher in today's build, the first automatically updated build after 4.0b11pre/20110201.
I renominate it for 2.0.

Comment 3

[Sheila Mooney]

I think we should see how this plays out in Beta11. It might be related to bug 629046 which was fixed. I can't find that many signatures for this. Scoobidiver, what query did you run to the stats for #11 top crash.

Comment 4

[Scoobidiver (away)]

> Scoobidiver, what query did you run to the stats for #11 top crash.
#11 was in 4.0b12pre/20110205 (it is now #19 in this build without hangs): 
https://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A4.0b12pre&build_id=20110205030343&do_query=1
Crashes are discontinuous: there are no crashes from 4.0b12pre/20110206. I am not sure we must block on it.

> It might be related to bug 629046 which was fixed.
It might even be a dupe but bug 629046 is not fully fixed.

Comment 5

[Sheila Mooney]

Great. So how about I remove the nomination but I will keep track of it to monitor for Beta11 and beyond. If it spikes up we can nominate again.

Comment 6

[John Daggett (:jtd)]

This crash appears to have a whole set of signatures.  

For b12pre:

https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox:4.0b12pre&query_search=signature&query_type=contains&query=gfx&date=02/13/2011%2023:45:56&range_value=2&range_unit=weeks&hang_type=crash&process_type=browser&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsTArray%3CnsColInfo,%20nsTArrayDefaultAllocator%3E::Clear()%20|%20nsTArray%3CDWRITE_GLYPH_OFFSET,%20nsTArrayDefaultAllocator%3E::~nsTArray%3CDWRITE_GLYPH_OFFSET,%20nsTArrayDefaultAllocator%3E()%20|%20gfxDWriteShaper::InitTextRun(gfxContext*,%20gfxTextRun*,%20unsigned%20short%20const*,...

https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox:4.0b12pre&query_search=signature&query_type=contains&query=gfx&date=02/13/2011%2023:45:56&range_value=2&range_unit=weeks&hang_type=crash&process_type=browser&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsTArray%3CnsListIter,%20nsTArrayDefaultAllocator%3E::Clear()%20|%20nsTArray%3CDWRITE_GLYPH_OFFSET,%20nsTArrayDefaultAllocator%3E::~nsTArray%3CDWRITE_GLYPH_OFFSET,%20nsTArrayDefaultAllocator%3E()%20|%20gfxDWriteShaper::InitTextRun(gfxContext*,%20gfxTextRun*,%20unsigned%20short%20const*...

https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox:4.0b12pre&query_search=signature&query_type=contains&query=gfx&date=02/13/2011%2023:45:56&range_value=2&range_unit=weeks&hang_type=crash&process_type=browser&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsTArray%3Ctag_SCRIPT_ITEM,%20nsTArrayDefaultAllocator%3E::Clear()%20|%20nsTArray%3CnsBlinkTimer::FrameData,%20nsTArrayDefaultAllocator%3E::~nsTArray%3CnsBlinkTimer::FrameData,%20nsTArrayDefaultAllocator%3E()%20|%20gfxDWriteShaper::InitTextRun(gfxContext*,%20gfxTextRun*,%20unsigned...

For b11:

https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox:4.0b11&query_search=signature&query_type=contains&query=gfx&date=02/13/2011%2023:55:57&range_value=2&range_unit=weeks&hang_type=crash&process_type=browser&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsTArray%3Cmozilla::DOMSVGPathSegList::ItemProxy,%20nsTArrayDefaultAllocator%3E::Clear()%20|%20nsTArray%3Cmozilla::widget::WindowHook::CallbackData,%20nsTArrayDefaultAllocator%3E::~nsTArray%3Cmozilla::widget::WindowHook::CallbackData,%20nsTArrayDefaultAllocator%3E()%20|%20gfxDW...

https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox:4.0b11&query_search=signature&query_type=contains&query=gfx&date=02/13/2011%2023:55:57&range_value=2&range_unit=weeks&hang_type=crash&process_type=browser&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsTArray%3CnsDOMWorker*,%20nsTArrayDefaultAllocator%3E::Clear()%20|%20nsTArray%3CPropItem*,%20nsTArrayDefaultAllocator%3E::~nsTArray%3CPropItem*,%20nsTArrayDefaultAllocator%3E()%20|%20gfxDWriteShaper::InitTextRun(gfxContext*,%20gfxTextRun*,%20unsigned%20short%20const*,%20unsigned%20int,%20un...

These all seem to be centered around the destruction of the various arrays set up within gfxDWriteShaper::InitTextRun:

http://hg.mozilla.org/mozilla-central/annotate/4c62984f12d1/gfx/thebes/gfxDWriteShaper.cpp#l224

  if (FAILED(hr)) {
      NS_WARNING("Analyzer failed to get glyph placements.");
      result = PR_FALSE;
*     break;
  }

This appears to been introduced by the changes on bug 602792 but some of those were backed out (i.e. lazy metrics initiailization of dwrite font objects) so I'm a bit baffled as to what the cause is here.

Comment 7

[John Daggett (:jtd)]

Argh, the crash-stats urls appear to be dependent on some sort of query info.  To replicate these results, search for b12pre, bll, etc builds that contain "gfx" in the signature.

Comment 9

[Scoobidiver (away)]

With combined signatures, there have been only 12 crashes in 4.0b12pre for the last week (filtered by gfxDWRITE):
https://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A4.0b12pre&platform=windows&branch=2.0&range_value=1&range_unit=weeks&query_search=signature&query_type=startswith&query=nsTArray%3C&build_id=&process_type=any&hang_type=any&do_query=1

It means that it is #97 top crasher in 4.0b12pre.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking based on comment 9, please renominate if the frequency increases.

Comment 11

[John Daggett (:jtd)]

(In reply to comment #10)
> Not blocking based on comment 9, please renominate if the frequency increases.

As noted in comment 6, this bug appears to have a whole set of signatures which often contain enough template poo to hide the fact that gfxDWriteShaper is involved.

For beta 11 crashers in the last two weeks, #50 on the list is a crash with this signature:

nsTArray<mozilla::DOMSVGPathSegList::ItemProxy, nsTArrayDefaultAllocator>::Clear() | nsTArray<mozilla::widget::WindowHook::CallbackData, nsTArrayDefaultAllocator>::~nsTArray<mozilla::widget::WindowHook::CallbackData, nsTArrayDefaultAllocator>() | gfxDW...

https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0b11&query_search=signature&query_type=contains&query=&date=02%2F14%2F2011%2021%3A28%3A17&range_value=2&range_unit=weeks&hang_type=crash&process_type=browser&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsTArray%3Cmozilla%3A%3ADOMSVGPathSegList%3A%3AItemProxy%2C%20nsTArrayDefaultAllocator%3E%3A%3AClear%28%29%20%7C%20nsTArray%3Cmozilla%3A%3Awidget%3A%3AWindowHook%3A%3ACallbackData%2C%20nsTArrayDefaultAllocator%3E%3A%3A~nsTArray%3Cmozilla%3A%3Awidget%3A%3AWindowHook%3A%3ACallbackData%2C%20nsTArrayDefaultAllocator%3E%28%29%20%7C%20gfxDW...

The common point of failure across all these is gfxDWriteShaper::InitTextRun, we're crashing during frame teardown when an error occurs:

http://hg.mozilla.org/mozilla-central/annotate/f9d66f4d17bf/gfx/thebes/gfxDWriteShaper.cpp#l224

With a beta 11 #50 crasher plus an additional set of related crash signatures I really think this should block.

Comment 12

[John Daggett (:jtd)]

Chris, could we get some URL data for the b11 top crasher listed in comment 11?

Comment 13

[Johnathan Nightingale [:johnath]]

Feels like this can be fixed on branch - still doesn't look big enough to hold release, though I'd love an answer on comment 12.

Comment 14

[chris hofmann]

looks like 100% of these are win7

test urls
  15 \N
  10 about:blank
   4 http://input.mozilla.com/happy
   3 https://addons.mozilla.org/fr/firefox/
   3 http://it.wikipedia.org/wiki/Amperometro
   3 http://input.mozilla.com/sad
   2 https://www.google.com/accounts/ServiceLoginAuth
   2 http://www.youtube.com/
   2 http://www.mozilla.com/es-ES/firefox/4.0b11/releasenotes/
   2 http://www.mozilla.com/en-US/mobile/beta/
   2 http://www.hi5.com/friend/trackClick.do?userId=407479878&r=2&hpc=false&numFriends=116&fu=AddedFriendV2%04407479878%041297708506395%04false%04%05407479878%05377647932%05183518108%05112558363%0557480623%05568887111&dest=%2Ffriend%2Fprofile%2FdisplayProfile.
   2 http://www.goal.com/en
   2 http://www.facebook.com/
   2 http://www.booking.com/index.html?aid=331521
   2 http://explore.live.com/worldwide-downloads
   2 http://el.wikipedia.org/wiki/%CE%A7%CE%B5%CE%AF%CF%81%CF%89%CE%BD
   2 http://el.wikipedia.org/wiki/%CE%98%CE%B5%CF%89%CF%81%CE%AF%CE%B1_%CF%85%CF%80%CE%BF%CE%BB%CE%BF%CE%B3%CE%B9%CF%83%CE%BC%CE%BF%CF%8D
   1 wyciwyg://0/http://www.freepatentsonline.com/y2007/0185354.html
   1 https://addons.mozilla.org/firefox/addon/748
   1 https://addons.mozilla.org/firefox/addon/15003
   1 https://addons.mozilla.org/firefox/
   1 https://addons.mozilla.org/es-ES/firefox/themes/modern?sort=name&page=4
   1 https://addons.mozilla.org/en-US/firefox/addon/ecology/contribute/roadblock/?src=addondetail&version=3.0
   1 http://www.youtube.com/watch?v=zSVsRy6NKSM
   1 http://www.youtube.com/watch?v=Sa2mXQzwqIY&feature=fvw
   1 http://www.youtube.com/watch?v=7Rr8zm8X4GM&feature=related
   1 http://www.youtube.com/watch?v=7Rr8zm8X4GM&NR=1
   1 http://www.youtube.com/redirect?q=https%3A%2F%2Faddons.mozilla.org%2Fes-ES%2Ffirefox&session_token=mn0sJE_pS5v4kfJtqB1UZJN9Omp8MTI5Nzc3MzE4Mg%3D%3D
   1 http://www.worldlingo.com/ma/enwiki/es/List_of_political_parties_in_Ecuador/1

domains of sites
  15 \N//
  10 about:blank//
   8 https://addons.mozilla.org
   7 http://www.youtube.com
   7 http://www.mozilla.com
   7 http://input.mozilla.com
   5 http://www.facebook.com
   5 http://el.wikipedia.org
   3 http://vkontakte.ru
   3 http://it.wikipedia.org
   2 https://www.google.com
   2 http://www.hi5.com
   2 http://www.google.it
   2 http://www.goal.com
   2 http://www.booking.com
   2 http://www.blogger.com
   2 http://fr.wikipedia.org
   2 http://explore.live.com
   2 http://clck.yandex.ru

Comment 15

[John Daggett (:jtd)]

I took at look at some of the crash dumps today.  The crashes appear to be failing on attempts to display languages like Korean.  Pages that appear to be English-only often contain things like a language menu with a pull-down list that contains Korean written in Hangul letters.  Not sure why Hangul requires shaping, but regardless, that's why we end up using the DirectWrite shaping code.

I think this may be related to a bug in the DirectWrite shaping code.  Looking over the OS versions where this crash occurs, the range for Windows 7 is something like:

6.1.7057 through 6.1.7137

The latest update of Windows 7 is 6.1.7600 and other bugs show the full range of values (in fact, seeing the version numbers above is somewhat rare).  This would sort of explain why installing IE9 requires several KB updates before the main IE install takes place.

I'm not sure whether we can update users to more recent versions of the OS but we can at least (1) show a page on startup telling users to update their OS and (2) blacklist DirectWrite usage on systems before and including 6.1.7137.

Since I think either of these should happen before FF4 ships rather than in a .x release, I'm going to ask that this block.

Comment 16

[John Daggett (:jtd)]

(In reply to comment #15)
> I think this may be related to a bug in the DirectWrite shaping code.  Looking
> over the OS versions where this crash occurs, the range for Windows 7 is
> something like:
> 
> 6.1.7057 through 6.1.7137
> 
> The latest update of Windows 7 is 6.1.7600 and other bugs show the full range
> of values (in fact, seeing the version numbers above is somewhat rare).  This
> would sort of explain why installing IE9 requires several KB updates before the
> main IE install takes place.

This also applies to the myriad of other stack signatures that crash at gfxDWriteShaper.cpp:224, they all show OS version numbers within the range above.

Comment 17

[Scoobidiver (away)]

DWrite.dll version 6.1.7600 has been introduced by the MS hotfix KB2454826.

Chris, what is the Beta 11 users' DWrite.dll breakdown (I don't talk about this kind of crash, but all the crashes)?

Comment 18

[Jonathan Kew [:jfkthame]]

(In reply to comment #15)
> I took at look at some of the crash dumps today.  The crashes appear to be
> failing on attempts to display languages like Korean.  Pages that appear to be
> English-only often contain things like a language menu with a pull-down list
> that contains Korean written in Hangul letters.  Not sure why Hangul requires
> shaping, but regardless, that's why we end up using the DirectWrite shaping
> code.

Korean requires shaping to support canonical composition of Hangul Jamo into syllables. Harfbuzz doesn't currently provide that, which is why we send Korean through the platform shaping path.

For example, go to http://www.i18nl10n.com/korean/hunmin.html and try setting gfx.font_rendering.harfbuzz.level to 3 and you'll see the Korean text break.

Comment 19

[chris hofmann]

(In reply to comment #17)
> DWrite.dll version 6.1.7600 has been introduced by the MS hotfix KB2454826.
> 
> Chris, what is the Beta 11 users' DWrite.dll breakdown (I don't talk about this
> kind of crash, but all the crashes)?

running a report to get a sample of 1000 reports from 4.0 beta11

preliminary results from the first 50 reports look like

  13  
   2 DWrite.dll 6.1.7100.0
   9 DWrite.dll 6.1.7600.16385
  23 DWrite.dll 6.1.7600.16699
   1 DWrite.dll 6.1.7600.20830
   1 DWrite.dll 6.1.7601.17514
   1 DWrite.dll 7.0.6002.18107
   2 DWrite.dll 7.0.6002.18392

Comment 20

[Jonathan Kew [:jfkthame]]

If this is primarily triggered by pages with Korean text, one way to mitigate it might be to switch to harfbuzz by default rather than directwrite for Hangul script. I've been experimenting with a patch to add Hangul composition to harfbuzz, which would fix the main rendering regression we'd get by switching; currently waiting to hear any comments from Behdad on it. (Currently, it would not implement full support for Old Korean, which requires additional OpenType features; that will take some extra work.)

Comment 21

[chris hofmann]

breakdown of 1000 reports from beta11 on feb 15

 353 DWrite.dll 6.1.7600.16699
 292  
 174 DWrite.dll 6.1.7600.16385
  69 DWrite.dll 6.1.7600.20830
  56 DWrite.dll 7.0.6002.18392
  17 DWrite.dll 6.1.7600.20781
  14 DWrite.dll 6.1.7601.17514
   8 DWrite.dll 7.0.6002.18107
   8 DWrite.dll 6.1.7100.0
   3 DWrite.dll 6.1.7601.17105
   3 DWrite.dll 6.1.7600.20655
   2 DWrite.dll 6.1.7106.0
   1 DWrite.dll 7.0.6002.18391
   1 DWrite.dll 6.1.7600.20710
   1 DWrite.dll 6.1.7264.0

Comment 22

[Scoobidiver (away)]

In reply to comment 21
1% of all crashes and 1.4% among those that have DWrite enabled has a DWrite.dll version lower than 6.1.7137.

In reply to comment 15
> (1) show a page on startup telling users to update their OS
It is useless as the MS hotfix KB2454826 is included in the Windows Update feature.
> (2) blacklist DirectWrite usage on systems before and including 6.1.7137.
I think this is the most cost effective solution vs the one in comment 20 (a bijective relation between crashes and Hangul scripts is not proved).

Comment 23

[Jeff Muizelaar [:jrmuizel]]

Attachment: Try to get better error reporting when this happens.

Comment 24

[Jeff Muizelaar [:jrmuizel]]

I don't think this should block for now. It doesn't seem to be really severe and we don't have really have a lot of good options to fix it. We should continue monitoring the problem and renominate if we know more or it gets worse. I've attached a patch that might help us get more info.

Comment 25

[Johnathan Nightingale [:johnath]]

Per comment 24, minusing. If we learn things, (particularly around our ability to fix it) and you judge it should block after all - please re-nom.

Comment 26

[John Daggett (:jtd)]

I looked a little more closely at Windows 7 version history today and it turns out the version numbers associated with this crash are from the pre-RTM RC build.  I had an old VM sitting around with the RC build on it, version 6.1.7100.  With it, I can reproduce the crash with these steps:

1. Download nightly trunk build
2. Create a new profile and enable DirectWrite
3. Open 'addons.mozilla.org'

Result: crash

The crash occurs rendering the Korean text in the language menu that appears at the bottom of the page.

I'm not sure why there are enough users with an RC build out there such that this bugs ends up in the top 50 crashers.  The version downloaded from Microsoft is out-of-date and shuts down every two hours.  I'm guessing that some folks are using some form of pirated version with this disabled.

Comment 27

[John Daggett (:jtd)]

I went through a random set of 10 crash dumps from the past week and in all cases the crash occurs within InitTextRun when script = 18 (i.e. HB_HANGUL).

So I think the immediate solution is to simply disable dwrite shaping for Hangul for the specific versions of dwrite causing the crash.  Something like:

  if (script is HB_HANGUL and Windows 7 and build <= 7137) {
    skip shaping with dwrite shaper (i.e. draw hex boxes)
  }

From what Jonathan has written, the reason we don't pass this to harfbuzz is due to the possibility of combining jamo characters.  But these aren't commonly used in modern Korean, I doubt many of the pages seeing this crash contain Korean strings with combining jamo in them.  So I think it might make sense to detect Hangul strings with no combining jamo and pass them to harfbuzz.  

But given that this is a single script with an outdated OS version, perhaps it's not worth the effort...

Comment 28

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #27)
> But given that this is a single script with an outdated OS version, perhaps
> it's not worth the effort...

I suggest we just disable D2D on the old versions.

Comment 29

[John Daggett (:jtd)]

Attachment: patch, disable DirectWrite usage for pre-Windows-RTM versions

Comment 30

[John Daggett (:jtd)]

Attachment: patch, disable DirectWrite usage for pre-Windows-RTM versions

Comment 31

[John Daggett (:jtd)]

I also did some sanity checking by explicitly failing all attempts to shape Hangul and no crash occurs (Korean pages become all hex-boxes of course).

Comment 32

[John Daggett (:jtd)]

Comment on attachment 512874 [details] [diff] [review]
Try to get better error reporting when this happens.

If we use the other patch, I don't think the crash reporter info is necessary.  If someone still wants to include it, I think we should add the script (aRunScript) along with the contents of the string and the name of the font.

Comment 33

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 513370 [details] [diff] [review]
patch, disable DirectWrite usage for pre-Windows-RTM versions

r+ before a?, please

Comment 34

[John Daggett (:jtd)]

Requesting approval 2.0.  This is a small patch that will workaround the potential for crashes on pre-RTM versions of Windows7.  The crash is currently #52 in the list of beta11 top crashers and is higher if all the associated crashes are factored in.  There's no impact on Windows 7 RTM and above machines, nor any on Vista/XP.

Comment 35

[Joe Drew (not getting mail)]

Comment on attachment 513370 [details] [diff] [review]
patch, disable DirectWrite usage for pre-Windows-RTM versions

I thought I had approved this literally hours ago :( sorry!

Comment 36

[Joe Drew (not getting mail)]

John, landing ping?

Comment 37

[John Daggett (:jtd)]

Landed on trunk
http://hg.mozilla.org/mozilla-central/rev/2b2fc7d3a193