1356399 - Crash in TrueTypeFontMetricsBuilder::GetBlackBox

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect, P4)

Description

[Andrew McCreight [:mccr8]]

This bug was filed from the Socorro interface and is 
report bp-ea346fd8-0b68-4ac5-bff3-0dc082170413.
=============================================================

This is the #3 top crash on Aurora for 4/13 build. There are 492 crashes on Aurora with this signature in the last week, across 10 installations, so presumably there's something terrible wrong with a few people's computers. I'm not sure if we can do anything about this, but I figured we should have a bug on file for such a common crash.

Comment 1

[Andrew McCreight [:mccr8]]

Jonathan, any ideas about what we might be able to do here?

Comment 2

[Jonathan Kew [:jfkthame]]

Not really, unless we can reproduce it, or get a user who is experiencing it to do some investigation -- e.g. disabling fonts until the problem stops happening, to isolate the font involved. (It looks like an internal DirectWrite crash that I'm guessing is specific to a certain font/version that has something anomalous about it....)

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to Jonathan Kew (:jfkthame) from comment #2)
> Not really, unless we can reproduce it, or get a user who is experiencing it
> to do some investigation -- e.g. disabling fonts until the problem stops
> happening, to isolate the font involved. (It looks like an internal
> DirectWrite crash that I'm guessing is specific to a certain font/version
> that has something anomalous about it....)

In Windows 7, does hiding a font suffice.  If not, is there an alternative process to avoid deleting?  (My win7 has 277 fonts)

Comment 4

[Ted Campbell [:tcampbell]]

Just FYI, these (remaining) crashes are all EXCEPTION_IN_PAGE_ERROR_READ with various disk errors. What is happening is that the font file is mmap'd and as Windows API touches pages in the buffer, the user's computers is reporting disk errors and the process is killed. https://bugzilla.mozilla.org/show_bug.cgi?id=771138#c4 gives some thoughts on these sort of issues that we hit in a few places of browser.

Comment 5

[Chris Peterson [:cpeterson]]

Five years later and we're still seeing 20–50 reports of this crash per day.

The crash reasons still all look like disk errors reported deep inside dwrite.dll:

EXCEPTION_IN_PAGE_ERROR_READ / STATUS_BAD_COMPRESSION_BUFFER
EXCEPTION_IN_PAGE_ERROR_READ / STATUS_DEVICE_DATA_ERROR
EXCEPTION_IN_PAGE_ERROR_READ / STATUS_IO_DEVICE_ERROR
EXCEPTION_IN_PAGE_ERROR_READ / STATUS_IO_TIMEOUT
EXCEPTION_IN_PAGE_ERROR_READ / STATUS_NO_SUCH_DEVICE
EXCEPTION_IN_PAGE_ERROR_READ / STATUS_UNEXPECTED_NETWORK_ERROR
EXCEPTION_IN_PAGE_ERROR_READ / STATUS_VOLUME_DISMOUNTED

Comment 6

[Daniel Holbert [:dholbert]]

lsalzman: I think we could probably downgrade to S3, given this doesn't seem to be actionable per comment 4 - 5. (and bug 771138 comment 4: "it's quite likely that if we're encountering them, then most profile I/O going forward is going to be broken too, so trading the crash for everything breaking isn't likely a major improvement. [...] As such I don't think there's much to do about the bug.")

(I'll defer to you on making that change, though.)

Comment 7

[Lee Salzman [:lsalzman]]

Jonathan, any idea if we can make these fallible somehow rather than just crash-bang-boom?

Comment 8

[Jonathan Kew [:jfkthame]]

I looked at a few of the reports, and in all the ones I checked, the failure is happening under gfxDWriteFont::GetGlyphBounds. So I guess we can add MOZ_SEH_TRY / MOZ_SEH_EXCEPT guards around the DirectWrite calls there (as we already have in some other methods) to catch the failure and just mark the font as invalid and hope to fall back to something usable.

There's always the possibility that catching the exception here just means we'll crash later on when some other system call wants to access a resource and hits a similar error, but it seems worth trying.

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1356399 - Try to catch DWrite font access exceptions within GetGlyphBounds. r=lsalzman

Comment 10

[Lee Salzman [:lsalzman]]

Attachment: Bug 1356399 - Use MOZ_SEH_TRY inside gfxDWriteFont::GetGlyphBounds. r?jfkthame

Comment 11

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

Re:

"it's quite likely that if we're encountering them, then most profile I/O going forward is going to be broken too, ...

I suspect this may not be the case... it depends, I think, whether we're running into a general disk access failure that will affect all accesses -- e.g. a drive got disconnected, or something equally drastic -- or a failure that's localized to a particular file, like a bad sector on an old platter. If it's the latter type of issue, then we may be able to skip using this font but carry on without serious breakage.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3bf11eb8a20b
Try to catch DWrite font access exceptions within GetGlyphBounds. r=lsalzman

Comment 13

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/3bf11eb8a20b