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.

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

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,

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.

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,

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.

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 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.

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 on attachment 486066 [details] [diff] [review] patch, v2 - don't allow UpdateRenderMode to switch to d2d if we're using GDI fonts Much better!