1173579 - Startup crash in mozalloc_abort(char const* const) | NS_DebugBreak | gfxFontGroup::GetDefaultFont() under Windows

Status: RESOLVED WONTFIX

(Core :: Graphics: Text, defect)

Description

[(Away)]

This bug was filed from the Socorro interface and is 
report bp-071a0821-7f56-44fe-a6a8-50c012150605.
=============================================================

The stack varies. On Windows this is only seen on Win7. On OSX it's mostly 10.10. 

From a spot-check of a few dumps, the abort message is usually:
"unable to find a usable font (serif)"

Comment 1

[(Away)]

[Tracking Requested - why for this release]: this is a top startup crash

Comment 2

[(Away)]

The NS_RUNTIMEABORT is unfortunate because this happens near startup, and presumably the affected users will hit this repeatedly, giving them no choice but to switch browsers.

Are there any other last-ditch efforts we could do to get a font? Or otherwise handle the failure more gracefully?

Comment 3

[jen strickland :jenstrickland]

Tracking enabled for 39, 40, and 41, due to top crash on Windows 7 and OSX 10.10.

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

Jet, startup crash with a text signature.  It seems like at the point where we crash there is not much to do, but do you have somebody that can figure out how we got that far without finding a usable font?

Comment 5

[Jet Villegas (inactive)]

(In reply to Milan Sreckovic [:milan] from comment #4)
> Jet, startup crash with a text signature.  It seems like at the point where
> we crash there is not much to do, but do you have somebody that can figure
> out how we got that far without finding a usable font?

Fun Times! I see reports all the way back to FF35 on this one. May be related to bug 998869. John should be online in a few hours to have a look.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

Great!

Comment 7

[John Daggett (:jtd)]

(In reply to Jet Villegas (:jet) from comment #5)
> (In reply to Milan Sreckovic [:milan] from comment #4)
> > Jet, startup crash with a text signature.  It seems like at the point where
> > we crash there is not much to do, but do you have somebody that can figure
> > out how we got that far without finding a usable font?
> 
> Fun Times! I see reports all the way back to FF35 on this one. May be
> related to bug 998869. John should be online in a few hours to have a look.

This bug has been around a *long* time, from before the work on bug 998869. The current signature is from bug 998869 because I moved around code in that area but the logic was from before -- if we can find *any* font, we bail. We need a way to figure out what exactly is causing the "no font available" condition. But I'm not sure the users hit this repeatedly, it seems to be something timing related at startup.

See bugs 636957, 1046547, 1070983. 

Note David Humphrey's comment: 

"No, I have no more info.  It was a one-time thing I've never seen again.  I suspect it related to the fact that I'd just updated my OS at the same time, and installing these coincided with needing to somehow rebuild the fontlist.  Sorry I have no more to offer."

https://bugzilla.mozilla.org/show_bug.cgi?id=636957#c15

Maybe this needs some dedicated testing to try and flush out? I tried with no luck.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

This is not super high volume for 39 beta. It is not in the top 50 crash signatures though it's in the top 10 for Mac crashes with 659 total crashes reported for the last month for all beta versions combined.

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

Noting this and leaving it tracked/affected for 39 in order to keep an eye on it next week during release.

Comment 10

[Robert Kaiser]

(In reply to Liz Henry (:lizzard) from comment #8)
> it's in the top 10 for Mac crashes with 659 total crashes
> reported for the last month for all beta versions combined.

That's actually pretty high for a startup crash. Note that people who can't launch Firefox will probably leave the beta channel or the product completely.

Comment 11

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Milan, I can see on crash-stats page that this crash is occurring on 40.0b4 in the last 7 days. Can you please help find an owner? Thanks!

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

See comment 7, it doesn't look like this is a new thing.  Is the volume very high?

Comment 13

[(Away)]

Volume, maybe not so much, but the severity is high. As a persistent crash near startup, the affected users have no choice but to switch browsers.

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: Take the first valid font (speculative fix). r=jdaggett

I can see this helping, and at least now the comment and the code match.

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

If this ends up helping, it's a simple enough fix to be easy to uplift.

Comment 16

[Jet Villegas (inactive)]

Jonathan: can you review Milan's patch? John's on PTO this week.

Comment 17

[Jonathan Kew [:jfkthame]]

Comment on attachment 8636684 [details] [diff] [review]
Take the first valid font (speculative fix). r=jdaggett

Review of attachment 8636684 [details] [diff] [review]:
-----------------------------------------------------------------

Agreed, this makes the code behave more like the comment claims.

AFAICS, there are two potential failure scenarios with the current code: (a) the font family list is empty, in which case we're still doomed even with this fix; or (b) there's a family at the end of the list for which FindOrMakeFont fails, so that mDefaultFont gets wiped out even though we actually found something usable already.

It's possible that some people are hitting (b), maybe as a result of a flaky font they've got installed (or perhaps some other kind of damage to their system), and if so, this might help them.

Comment 18

[Milan Sreckovic [:milan] (needinfo for best results)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=5a93d51eff10

Comment 19

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/26ecefcc6db8

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/26ecefcc6db8

Comment 21

[Lawrence Mandel [:lmandel] (use needinfo)]

Milan - What do you think about uplifting this patch for beta8?

Comment 22

[(Away)]

bp-843f461e-a0d4-420a-a64f-2dc852150727 crashed on nightly after the patch landed, so we shouldn't expect this to make the problem go away entirely. On the other hand, the patch can't really make things worse.

Comment 23

[Milan Sreckovic [:milan] (needinfo for best results)]

Have the numbers gone down?  If the number of crashes is the same before and after this, then no need to uplift it, we didn't find the actual fix.  If it improved things enough, I'm happy to ask for the uplift, it really should be quite safe.

Comment 24

[(Away)]

The volume is still in the same ballpark as before, but it's hard to say with so little data.

Maybe we should assume there's no improvement and keep looking for other fixes, but put the existing patch on beta anyway since it's such low risk.

Comment 25

[Lawrence Mandel [:lmandel] (use needinfo)]

We're also building the final beta, beta9 tomorrow, and the overall crash rate for 40 is good. We don't need to take a speculative fix at this point. I'm inclined to wait for 41 if there are no big objections.

Comment 26

[(Away)]

What makes this one particularly painful is that it's a persistent startup crash.

Comment 27

[Jonathan Kew [:jfkthame]]

I think we should simply re-open this, as it's clearly still happening; there are reports from both OS X and Windows for builds since the patch landed. My guess is the patch didn't help because the problem is that we're getting a completely empty font list, but I don't know why that happens.

Comment 28

[Milan Sreckovic [:milan] (needinfo for best results)]

Can we improve the message that comes from this a bit, or do we know already how this comes to be?  For example, is the defaultFamily non-null, and if so, what it is?  How many font families do we try?  Are we failing to find the font entry, or make/find the font itself?  I'm also not quite sure how mFamilyList plays into the picture (that's the font family we're reporting in the message) vs. all the other font-y things above.

Comment 29

[John Daggett (:jtd)]

(In reply to David Major [:dmajor] from comment #26)
> What makes this one particularly painful is that it's a persistent startup
> crash.

What's the data for this statement? I'm not sure this is correct. When I've found users who experienced this crash, they told me "happened once, then didn't happen". If you have evidence to indicate otherwise, that would be important.

Comment 30

[John Daggett (:jtd)]

(In reply to Milan Sreckovic [:milan] from comment #28)
> Can we improve the message that comes from this a bit, or do we know already
> how this comes to be?  For example, is the defaultFamily non-null, and if
> so, what it is?  How many font families do we try?  Are we failing to find
> the font entry, or make/find the font itself?  I'm also not quite sure how
> mFamilyList plays into the picture (that's the font family we're reporting
> in the message) vs. all the other font-y things above.

We only get into the abort code when something is *seriously* screwy. I suspect the problem is some form of initialization order bug. For example, some piece of code trying to grab metrics before gfxPlatform::Init has been called.

I don't think the problem actually lies close to the abort code and speculating a lot on what's going on at that point isn't helping. I think we need to annotate the crashstacks more and get to the bottom of what's causing this.

Comment 31

[John Daggett (:jtd)]

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #21)
> Milan - What do you think about uplifting this patch for beta8?

I don't think we need to uplift this patch.

Comment 32

[Wayne Mery (:wsmwk)]

#1 Mac crash for Thunderbird 38.1.0 and 31.7.0(#9 overall). So eventual uplift to esr would be helpful.

For Firefox it is currently #3 Mac crash for 39 and 38.0.1. And overall #49 and #44 respectively.

Comment 33

[(Away)]

(In reply to John Daggett (:jtd) from comment #29)
> (In reply to David Major [:dmajor] from comment #26)
> > What makes this one particularly painful is that it's a persistent startup
> > crash.
> 
> What's the data for this statement? I'm not sure this is correct. When I've
> found users who experienced this crash, they told me "happened once, then
> didn't happen". If you have evidence to indicate otherwise, that would be
> important.

That's based on the install time facet here: https://crash-stats.mozilla.com/search/?signature=~gfxFontGroup%3A%3AGetDefaultFont&uptime=%3C60&_facets=install_time#facet-install_time (I excluded the release channel to minimize install-time collisions.) Perhaps some installations may survive, but others don't.

Comment 34

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to John Daggett (:jtd) from comment #30)
> ...
> I don't think the problem actually lies close to the abort code and
> speculating a lot on what's going on at that point isn't helping. I think we
> need to annotate the crashstacks more and get to the bottom of what's
> causing this.

Got it.  You're right, my system doesn't even go into GetDefaultFont(), though it does survive it if I force the call.

Comment 35

[u279076]

Marking this as a topcrash for Mac since this remains the #3 crash for Mac OS X Firefox users.

Comment 36

[John Daggett (:jtd)]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #35)
> Marking this as a topcrash for Mac since this remains the #3 crash for Mac
> OS X Firefox users.

This is the wrong bug for that, please mark bug 1070983 instead. Symptoms are the same but I suspect the causes are not completely the same.

Comment 37

[John Daggett (:jtd)]

After the moving the font loader thread shutdown code into an event, I haven't seen GetDefaultFont aborts under OSX. However, there's been a trickle of aborts on Windows.

I landed some better crashstack annotations with bug 1189129 last week. These seem to indicate that when the abort occurs, the system fontlist has been initialized but contains no fonts (and the fontloader thread has not yet started to collect font data). One thing that seems like it might cause this is if in the DirectWrite case the lazy call to gfxDWriteFontList::DelayedInitFontList doesn't happen before GetDefaultFont is called.

I've logged bug 1192699 to fix that.

Comment 38

[Wayne Mery (:wsmwk)]

I spot checked some Windows Thunderbird and Firefox crashes. Some are like comment 0's bp-071a0821-7f56-44fe-a6a8-50c012150605  But there is some variety

Firefox 42.0a1
bp-128520de-9aff-4b2b-b540-422a42150810 like the stack cited in bug 1189129
GraphicsCriticalError 	|[0][GFX1]: no fonts - init: 1 fonts: 0 loader: 0
0 	mozglue.dll	mozalloc_abort(char const* const)	memory/mozalloc/mozalloc_abort.cpp
1 	xul.dll	NS_DebugBreak	xpcom/base/nsDebugImpl.cpp
2 	xul.dll	gfxFontGroup::GetDefaultFont()	gfx/thebes/gfxTextRun.cpp
3 	xul.dll	gfxFontGroup::GetFirstValidFont(unsigned int)	gfx/thebes/gfxTextRun.cpp
4 	xul.dll	nsBlockReflowState::nsBlockReflowState(nsHTMLReflowState const&, nsPresContext*, nsBlockFrame*, bool, bool, bool, int)	layout/generic/nsBlockReflowState.cpp
5 	xul.dll	nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&)	layout/generic/nsBlockFrame.cpp
6 	xul.dll	nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, mozilla::WritingMode const&, mozilla::LogicalPoint const&, nsSize const&, unsigned int, unsigned int&, nsOverflowContinuationTracker*)	layout/generic/nsContainerFrame.cpp
7 	xul.dll	nsCanvasFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&)	layout/generic/nsCanvasFrame.cpp
8 	xul.dll	nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, mozilla::WritingMode const&, mozilla::LogicalPoint const&, nsSize const&, unsigned int, unsigned int&, nsOverflowContinuationTracker*)	layout/generic/nsContainerFrame.cpp
9 	xul.dll	nsHTMLScrollFrame::ReflowScrolledFrame(ScrollReflowState*, bool, bool, nsHTMLReflowMetrics*, bool)	layout/generic/nsGfxScrollFrame.cpp 

Firefox 41.0a2
bp-586ea736-527e-4276-840f-8024c2150807
 0 	mozglue.dll	mozalloc_abort(char const* const)	memory/mozalloc/mozalloc_abort.cpp
1 	xul.dll	NS_DebugBreak	xpcom/base/nsDebugImpl.cpp
2 	xul.dll	gfxFontGroup::GetDefaultFont()	gfx/thebes/gfxTextRun.cpp
3 	xul.dll	gfxFontGroup::GetFirstValidFont(unsigned int)	gfx/thebes/gfxTextRun.cpp
4 	xul.dll	nsBlockReflowState::nsBlockReflowState(nsHTMLReflowState const&, nsPresContext*, nsBlockFrame*, bool, bool, bool, int)	layout/generic/nsBlockReflowState.cpp
5 	xul.dll	nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&)	layout/generic/nsBlockFrame.cpp
6 	xul.dll	nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, mozilla::WritingMode const&, mozilla::LogicalPoint const&, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*)	layout/generic/nsContainerFrame.cpp
7 	xul.dll	nsCanvasFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&)	layout/generic/nsCanvasFrame.cpp
8 	xul.dll	nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, mozilla::WritingMode const&, mozilla::LogicalPoint const&, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*)	layout/generic/nsContainerFrame.cpp
9 	xul.dll	nsHTMLScrollFrame::ReflowScrolledFrame(ScrollReflowState*, bool, bool, nsHTMLReflowMetrics*, bool)	layout/generic/nsGfxScrollFrame.cpp
10 	xul.dll	nsHTMLScrollFrame::ReflowContents(ScrollReflowState*, nsHTMLReflowMetrics const&)	layout/generic/nsGfxScrollFrame.cpp
11 	xul.dll	nsHTMLScrollFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&)	layout/generic/nsGfxScrollFrame.cpp 


Most Firefox 39.0 are like 
bp-eaf3cc75-6ba9-45b9-bec9-dc1e92150805
 0 	mozalloc.dll	mozalloc_abort(char const* const)	memory/mozalloc/mozalloc_abort.cpp
1 	xul.dll	NS_DebugBreak	xpcom/base/nsDebugImpl.cpp
2 	xul.dll	gfxFontGroup::GetDefaultFont()	gfx/thebes/gfxTextRun.cpp
3 	xul.dll	gfxFontGroup::GetFirstValidFont(unsigned int)	gfx/thebes/gfxTextRun.cpp
4 	xul.dll	nsHTMLReflowState::CalcLineHeight(nsIContent*, nsStyleContext*, int, float)	layout/generic/nsHTMLReflowState.cpp
5 	xul.dll	nsBlockReflowState::nsBlockReflowState(nsHTMLReflowState const&, nsPresContext*, nsBlockFrame*, bool, bool, bool, int)	layout/generic/nsBlockReflowState.cpp
6 	xul.dll	nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&)	layout/generic/nsBlockFrame.cpp
7 		@0xb54cfff	
8 		@0x2ef0d3

Comment 39

[John Daggett (:jtd)]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #38)
> I spot checked some Windows Thunderbird and Firefox crashes. Some are like
> comment 0's bp-071a0821-7f56-44fe-a6a8-50c012150605  But there is some
> variety

Yeah, these are all basically "reflow occurred when the system fontlist was empty". That should never, ever happen.

The patch I landed for bug 1192699 does two things, it eliminates a potential scenario where lazy initialization doesn't happen correctly and it puts in an explicit check for the fontlist being empty. If for some reason the fontlist is empty, it forces fallback to the GDI fontlist.

Comment 40

[John Daggett (:jtd)]

Looking at the crashreports for the latest beta builds, which contain the font loader thread fix, but not the annotations or the DirectWrite fontlist merge fixes, these crashes occur only in non-updated Windows 7 machines. The version of the dwrite.dll is always 6.1.7600 or 6.1.7601, so I suspect there's some underlying bug in that code that under certain conditions returns an error during fontlist initialization under DirectWrite.

https://crash-stats.mozilla.com/signature/?product=Firefox&version=41.0b&signature=mozalloc_abort%28char+const*+const%29+|+NS_DebugBreak+|+gfxFontGroup%3A%3AGetDefaultFont%28%29&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=platform_version&_columns=uptime&page=1

Latest version of the dwrite.dll on my updated Windows 7 machine: 6.2.9200.1792

Comment 41

[Sylvestre Ledru [:Sylvestre]]

Updating the tracking flags: this is affecting 42 & 43 but it is too late for 40

Comment 42

[John Daggett (:jtd)]

Analyzing beta crashreports for this, associated dwrite.dll versions with counts:

  34 6.1.7600.16385
  43 6.1.7601.17514
   1 6.2.9200.17292
   3 6.2.9200.17461
   5 6.3.9600.17999

So this is primarily affecting only Windows 7 RTM and SP1 users but not exclusively.

Comment 43

[John Daggett (:jtd)]

After landing bug 1192699, these aborts have pretty much stopped but not completely:

https://crash-stats.mozilla.com/report/index/70f09822-6e67-47b5-a842-1d5752150826
https://crash-stats.mozilla.com/report/index/799c5ba0-44ae-41dc-a771-920192150826
https://crash-stats.mozilla.com/report/index/9d0016c2-42c0-442e-8797-0f9fb2150826

All reports annotated with:

no fonts - init: 1 fonts: 0 loader: 1 backend: directwrite

Mystifying...

Comment 44

[Milan Sreckovic [:milan] (needinfo for best results)]

Is this still a top crash?  If not, we should probably wontfix for 41, perhaps 42 as well.

Comment 45

[u279076]

(In reply to Milan Sreckovic [:milan] from comment #44)
> Is this still a top crash?  If not, we should probably wontfix for 41,
> perhaps 42 as well.

There's a few different stories here.

> [@ mozalloc_abort | Abort | NS_DebugBreak | gfxFontGroup::GetDefaultFont ]
This signature has gone completely.

> [@ mozalloc_abort(char const*) | Abort | NS_DebugBreak | gfxFontGroup::GetDefaultFont() ]
This signature is gone for Firefox Beta, Aurora, and Nightly but still exists for Firefox Release with 1466 crashes, making it the #53 topcrash for Firefox Release. For Thunderbird this shows up with 3 crashes in Beta and 517 in Release making it the #17 topcrash.

> [@ mozalloc_abort(char const* const) | NS_DebugBreak | gfxFontGroup::GetDefaultFont() ]
For Firefox this shows up with 2 crashes in Nightly, 9 in Aurora, 178 in Beta, and 611 in Release making it the #48 topcrash. For Thunderbird this shows up with 3 crashes in Beta and 24 in Release making it the #291 topcrash.

If we combine the signatures this is #6 for Firefox and #14 for Thunderbird in Release. I think this bug should still be treated as a topcrash but given the volume on test branches maybe it doesn't need to be tracked anymore. It might be prudent to wait until Firefox 41 is released to see what happens.

Comment 46

[(Away)]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #45)

Note that those variants only differ in parameter verbosity, which is a result of coming from different compilers. Offhand I think the "const* const" looks like OS X. It would probably be best to figure out which one is Windows and just look at that, since the other platforms may not have enough volume to see clear changes.

(This will all become moot very shortly when bug 1171437, currently on stage, reaches production)

Comment 47

[u279076]

> [@ mozalloc_abort(char const* const) | NS_DebugBreak | gfxFontGroup::GetDefaultFont() ]
This is 98% on Windows 7 and 2% on other Windows versions.

> [@ mozalloc_abort(char const*) | Abort | NS_DebugBreak | gfxFontGroup::GetDefaultFont() ]
This is 51% on Mac OS 10.10 and 49% on other Mac OS versions.

If we're just looking at the Windows crash, taking the stats from above, this is outside the range of what we'd traditionally define as a "topcrash".

Comment 48

[John Daggett (:jtd)]

There were a variety of reasons this abort crash occurred. This bug is for tracking the causes of this under *Windows*, not OSX. Bugs for specific cases (e.g. bug 1189158, bug 1192699) have resolved the problem on OSX and, for the most part, on Windows also. I doubt this is still a top-crasher for builds after those two landed upstream.

As mentioned in comment 43, these aborts still occur, so there's more to be done. So I'm leaving this open until those remaining issue(s) are resolved.

Comment 49

[John Daggett (:jtd)]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #47)
> > [@ mozalloc_abort(char const* const) | NS_DebugBreak | gfxFontGroup::GetDefaultFont() ]
> This is 98% on Windows 7 and 2% on other Windows versions.
> 
> > [@ mozalloc_abort(char const*) | Abort | NS_DebugBreak | gfxFontGroup::GetDefaultFont() ]
> This is 51% on Mac OS 10.10 and 49% on other Mac OS versions.
> 
> If we're just looking at the Windows crash, taking the stats from above,
> this is outside the range of what we'd traditionally define as a "topcrash".

I concur. The fixes for 1189158 and 1192699 have both been pushed to the 41/42 trees so I think that should be sufficient to greatly reduce the rate at which these abort crashes occur.

Comment 50

[Robert Kaiser]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #45)
> > [@ mozalloc_abort | Abort | NS_DebugBreak | gfxFontGroup::GetDefaultFont ]
> This signature has gone completely.

Actually, it may just not have appeared yet - but it is what this will look like once the changes in bug 1171437 actually go live in Socorro (we are waiting for the dependencies on both sides to get fixed before we do that).

Comment 51

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

This in #16 spot for 41.0b on crash-stats. Wontfix for 41.

Comment 52

[John Daggett (:jtd)]

(In reply to Ritu Kothari (:ritu) from comment #51)
> This in #16 spot for 41.0b on crash-stats. Wontfix for 41.

Those include many builds before the fix for bug 1192699 was uplifted to 41. I think these crashes will significantly decrease in frequency after that change. I doubt it will make the top 100 for builds after 8/24.

Comment 53

[Sylvestre Ledru [:Sylvestre]]

Indeed, the crash still exist but gone from the top 100 list. I am going to untrack it then.

Comment 54

[u279076]

> mozalloc_abort | Abort | NS_DebugBreak | gfxFontGroup::GetDefaultFont
This is 100% on Mac OS X with only 1 / 1298 crashes being in Firefox 41.0.2. 

> mozalloc_abort | NS_DebugBreak | gfxFontGroup::GetDefaultFont
This was reported 49 times in the last week for Firefox 41.0.2.

I suggest we close this bug if we're not going to fix up the outliers.

Comment 55

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

The Socorro reports show that this crash is still encountered by many people. My 44.0.2 Firefox version didn't crash at startup, but I believe we should leave this bug open until there are no more, or just a few crashes with the same signature.

Comment 56

[u279076]

(In reply to Paul Pasca[:PoollyMcklayn] from comment #55)
> The Socorro reports show that this crash is still encountered by many
> people. My 44.0.2 Firefox version didn't crash at startup, but I believe we
> should leave this bug open until there are no more, or just a few crashes
> with the same signature.

I think it's important to look at this more deeply than just the overall numbers.

> [@ mozalloc_abort(char const* const) | NS_DebugBreak | gfxFontGroup::GetDefaultFont() ]

This signature does not show up at all anymore.

> [@ mozalloc_abort(char const*) | Abort | NS_DebugBreak | gfxFontGroup::GetDefaultFont() ]

Nor does this signature.

> [@ mozalloc_abort | Abort | NS_DebugBreak | gfxFontGroup::GetDefaultFont ]

This signature shows up exclusively on Mac and with no crashes beyond Firefox 40 / Thunderbird 38. I'm not sure there's anything we can do for these people apart from encouraging them to redownload a modern version. Of course that's assuming we can even get in touch with these people and that they're willing/capable of downloading and installing software on their systems.

> [@ mozalloc_abort | NS_DebugBreak | gfxFontGroup::GetDefaultFont ]

This signature is the only one that shows up for modern versions of Firefox and Thunderbird.
* Firefox 47.0a1 has 1 report  (1 user affected)
* Firefox 46.0a2 has 0 reports (0 users affected)
* Firefox 45.0b* has 5 reports (3 users affected)
* Firefox 44.0.* has 5 reports (4 users affected)
* Thunderbird 38.6 has 0 reports (0 users affected)
* Thunderbird 38.5 has 28 reports (25 users affected)

Quite frankly I don't see a point in keeping this bug report open unless we're going to put engineering effort into resolving this 100%. Considering this issue is a drop in the ocean I'm not sure it's worth it.

I will leave the final call to either John Daggett or someone on Release Management.

Comment 57

[u279076]

I'm closing this bug report given that no one has chimed in on my previous comment. Please reopen this bug report if it's something we're going to attempt to fix.