594865 - Firefox 4.0b5 Crash [@ gfxDWriteFontList::InitFontList() ]

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[chris hofmann]

might have first appeared on aug23 in 4.0b5pre builds from aug21

date     tl crashes at, count build, count build, ...
         gfxDWriteFontList::InitFontList..
20100820
20100821
20100822
20100823 1 ,1 4.0b5pre2010082104
20100824 9 ,7 4.0b5pre2010082404 ,2 4.0b42010081813
20100825 1 ,1 4.0b5pre2010082305
20100826 8 ,8 4.0b42010081813

spiked to #25 top crash 

when b5 was released


stack looks like

http://crash-stats.mozilla.com/report/index/93b202ff-6bab-4d16-a4ee-4f74c2100909

Frame  	Module  	Signature [Expand]  	Source
0 	xul.dll 	gfxDWriteFontList::InitFontList 	gfx/thebes/gfxDWriteFontList.cpp:489
1 	xul.dll 	gfxPlatformFontList::Init 	gfx/thebes/gfxPlatformFontList.h:72
2 	xul.dll 	gfxPlatform::Init 	gfx/thebes/gfxPlatform.cpp:266
3 	xul.dll 	nsComponentManagerImpl::KnownModule::Load 	xpcom/components/nsComponentManager.cpp:938
4 	xul.dll 	nsFactoryEntry::GetFactory 	xpcom/components/nsComponentManager.cpp:1918
5 	xul.dll 	nsComponentManagerImpl::CreateInstance 	xpcom/components/nsComponentManager.cpp:1193
6 	xul.dll 	CallCreateInstance 	obj-firefox/xpcom/build/nsComponentManagerUtils.cpp:157
7 	xul.dll 	nsBaseWidget::BaseCreate 	widget/src/xpwidgets/nsBaseWidget.cpp:210
8 	xul.dll 	nsWindow::Create 	widget/src/windows/nsWindow.cpp:547
9 	xul.dll 	nsWebShellWindow::Initialize 	xpfe/appshell/src/nsWebShellWindow.cpp:211
10 	xul.dll 	nsACString_internal::AssignASCII 	xpcom/string/src/nsTSubstring.cpp:356

more at

http://crash-stats.mozilla.com/report/list?signature=gfxDWriteFontList::InitFontList%28%29

100% windows 7

no urls reported.

looks like a start up crash.

45 total crashes for gfxDWriteFontList::InitFontList.. on 20100908-crashdata.csv
28 startup crashes inside 30 sec.
45 startup crashes inside 3 min.

A couple of comments from a user that might have been confused about which beta was being updated to...  the person reported the crash from a b5 build.
* Crash occured during Beta 4 update process I believe
* It would now seem that the updated Beta 4 will not load.

Comment 2

[Marcia Knous [:marcia]]

Not sure why Bugzilla did not find that stack in my search...

Comment 3

[chris hofmann]

around 2-11 crashes the last few weeks, but a jump in volume yesterday

#7 topcrash on trunk and possible regression since last beta. might be a couple of users or combination of dups across a couple of builds.  this probably should block b7 if the same spike continues as we saw yeterday on builds from oct 11 and oct 12.

date     tl crashes at, count build, count build, ...
         gfxDWriteFontList::InitFontList..
20101005 11 4.0b62010091408 11 , 
20101006 4 4.0b62010091408 4 , 
20101007 4 4.0b62010091408 4 , 
20101008 7  6 4.0b62010091408, 
	     1 4.0b52010083108, 
20101009 2 4.0b62010091408 2 , 
20101010 8 4.0b62010091408 8 , 
20101011 15  14 4.0b62010091408, 
	     1 4.0b7pre2010091404, 
20101012 8 4.0b62010091408 8 , 
20101013 35  18 4.0b8pre2010101304, 
	     13 4.0b8pre2010101204, 4 4.0b62010091408,

Comment 4

[Jonathan Kew [:jfkthame]]

These crashes all seem to indicate a NULL-deref at gfx/thebes/gfxDWriteFontList.cpp:489, which means that the DirectWrite call GetSystemFontCollection() must have failed, leaving the systemFonts pointer NULL. In debug builds, we have an assertion which would flag this, but we don't have any protection against the subsequent crash.

We could make gfxDWriteFontList::InitFontList() do an early return here, leaving the font list empty, but that will only lead to an NS_RUNTIMEABORT in gfxFontGroup::BuildFontList() when no usable fonts - not even a last-ditch fallback - can be found.

When GetSystemFontCollection() fails, I don't see any way we can continue to use dwrite and d2d; our only chance of recovery, it seems, would be to fall back to GDI-based drawing. But I'm not sure how feasible this is by the time we discover the failure.

Comment 5

[chris hofmann]

the 4.0b8pre spike on oct 13 looks like an anomaly and hasn't been sustained, so final+ is probably a good assignment. 

date     tl crashes at, count build, count build, ...
         gfxDWriteFontList::InitFontList..
20101014 15  5 4.0b8pre2010101322, 1 4.0b8pre2010101404,  
20101015 12  6 4.0b8pre2010101404,  
20101016 18  4 4.0b8pre2010101504, 
20101017 18  5 4.0b8pre2010101704, 4 4.0b8pre2010101604, 
20101018 7 
20101019 15 
20101020 8   1 4.0b8pre2010102004,

Comment 6

[Jonathan Kew [:jfkthame]]

The "spike" on Oct 13 is largely due to a single user, perhaps with a damaged system, repeatedly trying to launch Firefox; many of the crashes there occur within a timespan of a couple of minutes, and show an uptime of 1 or even 0.

As far as I can see, this crash occurs when something goes wrong inside DirectWrite, such that the GetSystemFontCollection() call fails. I have no idea what could cause this - I'm guessing it may well be indicative of some kind of problem on the user's system, such as corrupted fonts or maybe even some kind of malware.

I'm working on a patch to handle this failure by switching over to GDI rendering when the DWrite call fails, rather than proceeding to try and work with a broken font-list object.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: patch, v1 - fall back to GDI if GetSystemFontCollection() fails

I don't know what causes this DWrite call to fail, but from the crash reports it appears to happen occasionally in the wild. We can't proceed with an empty font list, so this patch handles the failure by switching to the GDI-based font list and RENDER_GDI mode instead.

(To do this, I rearranged the code slightly so that the CreatePlatformFontList() function is responsible to call InitFontList(), not just create the desired subclass of gfxPlatformFontList; this is so that it has the opportunity to check for failure and try to take remedial action.)

Comment 8

[Bas Schouten (:bas.schouten)]

Comment on attachment 485258 [details] [diff] [review]
patch, v1 - fall back to GDI if GetSystemFontCollection() fails

I believe the current patch is the wrong way of falling back. This will change the render mode used at that point in time. But as soon as UpdateRenderMode gets called (which may get called on a device reset for example), it will go back to D2D. UpdateRenderMode will need to have code dealing with this situation.

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: patch, v2 - don't allow UpdateRenderMode to switch to d2d if we're using GDI fonts

Hmm, this seems like a more general problem with UpdateRenderMode, then. If the platform has been initialized using GDI fonts rather than DWrite fonts (perhaps because of user prefs at startup time, which may have been modified since), then UpdateRenderMode must not be allowed to choose D2D rendering, regardless of current prefs and device capabilities.

This version of the patch adds a flag mUsingGDIFonts to the platform object, and if this is set then d2d is disabled.

A more sophisticated approach would be to enable UpdateRenderMode to switch the platform from GDI to DWrite fonts on the fly, but I'm not sure how easy or reliable that would be (we'd have to make sure all cached font objects get flushed properly) and I don't think it's worth the effort for such a "corner case" situation.

Comment 10

[Bas Schouten (:bas.schouten)]

Comment on attachment 486066 [details] [diff] [review]
patch, v2 - don't allow UpdateRenderMode to switch to d2d if we're using GDI fonts

Much better!

Comment 11

[Jonathan Kew [:jfkthame]]

http://hg.mozilla.org/mozilla-central/rev/a0826dcd6228