Open Bug 1264504 Opened 4 years ago Updated 3 years ago

crash in gfxFontGroup::GetFirstValidFont


(Core :: Graphics: Text, defect, P3, critical)

45 Branch
Windows NT



Tracking Status
firefox45 - affected
firefox46 --- affected


(Reporter: u279076, Unassigned)


(Keywords: crash, Whiteboard: gfx-noted)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-bfb2b56c-8851-46e8-ab4b-4c76f2160413.
0 	xul.dll 	gfxFontGroup::GetFirstValidFont(unsigned int) 	gfx/thebes/gfxTextRun.cpp
1 	d3d11.dll 	ATL::AtlInternalQueryInterface(void*, ATL::_ATL_INTMAP_ENTRY const*, _GUID const&, void**) 	
2 	xul.dll 	gfxFontGroup::MakeTextRun(wchar_t const*, unsigned int, gfxTextRunFactory::Parameters const*, unsigned int, gfxMissingFontRecorder*) 	gfx/thebes/gfxTextRun.cpp
3 	xul.dll 	`anonymous namespace'::AutoTextRun::AutoTextRun(nsFontMetrics*, nsRenderingContext*, wchar_t const*, int) 	gfx/src/nsFontMetrics.cpp
4 	xul.dll 	nsFontMetrics::DrawString(wchar_t const*, unsigned int, int, int, nsRenderingContext*, nsRenderingContext*) 	gfx/src/nsFontMetrics.cpp
5 	xul.dll 	nsTextBoxFrame::DrawText(nsRenderingContext&, nsRect const&, nsRect const&, unsigned int const*) 	layout/xul/nsTextBoxFrame.cpp
6 	xul.dll 	nsTextBoxFrame::PaintTitle(nsRenderingContext&, nsRect const&, nsPoint, unsigned int const*) 	layout/xul/nsTextBoxFrame.cpp
More reports:

This is a low volume crash but it's spiking a bit today on 45.0.2 - we've gone from 0.16 crashes per million ADU a week ago to just over 11 crashes per million ADU today. It's not high volume (#45 on release) but I am a little concerned about the spike. The spike seems to correlate to the release of 45.0.2 so maybe something regressed in this point release.

The comments seem to indicate this is isolated to several users crashing multiple times.
> This is the 6th time it's happened in the past 10 minutes up updating Firefox.
> Firefox has been crashing a lot for two days. Seems to happen when I have multiple tabs open.
> 5th time Firefox has crashed today. I'll IE the rest of the day until you get this fixed.
> AGAIN??? Crashing crashing again and again 4 times now 

This is highly correlated to users with AMD Llano integrated GPUs on Windows 7:
> 40% are on Radeon HD 6520G (0x9647)
> 26% are on Radeon HD 6530D (0x964a)
> 10% are on Radeon HD 6480G (0x9648)
> 10% are on Radeon HD 6550D (0x9640)
>  9% are on Radeon HD 6620G (0x9641)

Unfortunately I'm having problems authenticating to Socorro so I cannot get URL correlations at this time.

Here's the pushlog for 45.0.2:
[Tracking Requested - why for this release]: nominating to track since this appears to be a regression in 45.0.2 and a significant issue for a specific group of users.

Milan, I'm not sure who best to look at this.
Flags: needinfo?(milan)
Version: 48 Branch → 45 Branch
I don't think the spike is related to the 45.0.2 changes, but I could be wrong. Perhaps we are just hitting different target audience (we have seen another unrelated font crash spike like that, but not related to any changes during that timeframe.)
Flags: needinfo?(milan) → needinfo?(jfkthame)
Without being able to reproduce this, I don't really have any ideas here. I'm not aware of any recent changes in the font code that would seem likely to be relevant.

A couple of random thoughts:

- In virtually all the reports, the crash is EXCEPTION_ACCESS_VIOLATION_WRITE, and it's always at 0xfffffffffffffffc. And in all the cases I looked at, it appears that the crash is happening when drawing XUL text (e.g. under nsTextBoxFrame::PaintTitle) rather than in web content. So I'm guessing this is about a font being used in browser (or add-on) chrome, rather than HTML content.

- I see from the 45.0.2 pushlog that a new version of the Loop system add-on was included. Does the Loop add-on use a special font at all? Did its font change, or did it add languages such that it may be exercising fonts in new ways?
Flags: needinfo?(jfkthame)
Something very... interesting... is going on here but I've no idea what just yet.

For one thing, the stacks on crash-stats make no sense. The stack from the crash dump itself is sane, though:

xul!gfxFontGroup::GetFirstValidFont+0x3 [gfx\thebes\gfxtextrun.cpp @ 1871]
xul!gfxFontGroup::InitScriptRun<wchar_t>+0x2f [gfx\thebes\gfxtextrun.cpp @ 2325]
xul!gfxFontGroup::InitTextRun<wchar_t>+0x211 [gfx\thebes\gfxtextrun.cpp @ 2257]
xul!gfxFontGroup::MakeTextRun+0x10c [gfx\thebes\gfxtextrun.cpp @ 2123]
xul!`anonymous namespace'::AutoTextRun::AutoTextRun+0x50 [gfx\src\nsfontmetrics.cpp @ 49]
xul!nsFontMetrics::DrawString+0x2e [gfx\src\nsfontmetrics.cpp @ 383]
xul!nsTextBoxFrame::DrawText+0x2f5 [layout\xul\nstextboxframe.cpp @ 577]
xul!nsTextBoxFrame::PaintTitle+0x40 [layout\xul\nstextboxframe.cpp @ 384]
xul!nsDisplayXULTextBox::PaintTextToContext+0x2f [layout\xul\nstextboxframe.cpp @ 345]
xul!PaintTextShadowCallback+0x20 [layout\xul\nstextboxframe.cpp @ 317]
xul!nsDisplayXULTextBox::Paint+0x626fcd [layout\xul\nstextboxframe.cpp @ 333]

And the other thing is that we appear to be crashing on a PUSH instruction, but ESP looks to be valid in the dump. The crash reports say we were trying to write to 0xfffffffffffffffc, which would make ESP = 0.

It's also very suspicious that most of these reports are happening over such a narrow range of setups...
I suspect this is one of those bugs in which we have randomly triggered some "helpful" heuristic behaviour in a driver somewhere.

I think it's worth waiting for users to take up 46.0 and seeing whether it crashes as well. If not, it might still be worth finding the root cause but this doesn't look to be affecting all that many users.
You need to log in before you can comment on or make changes to this bug.