Open Bug 1407741 Opened 7 years ago Updated 1 year ago

Crash in ComputeCrc32

Categories

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

55 Branch
Unspecified
Windows 10
defect

Tracking

()

Tracking Status
firefox-esr52 --- affected
firefox56 --- wontfix
firefox57 --- fix-optional
firefox58 --- affected

People

(Reporter: jesup, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, Whiteboard: [gfx-noted])

Crash Data

This bug was filed from the Socorro interface and is 
report bp-913f6649-6b17-46e3-b350-ba3840171007.
=============================================================

There are a lot of DWriteFont GFX Thebes font failures with wildptrs with 'reason' of EXCEPTION_IN_PAGE_ERROR_READ / STATUS_DEVICE_DATA_ERROR
I presume that reason means a wildptr, so marking sec-high.

These go back to at least FF 32.  All the recent failures seem to be in CreateFontFace(); older ones are elsewhere as well I think.

Not sure who should look at this part of gfx
[@ ScopedArray<T>::ScopedArray<T> ] seems related - though note that every crash there seems to be from the same system/install, crashing repeatedly.
Crash Signature: [@ ComputeCrc32] → [@ ComputeCrc32] [@ ScopedArray<T>::ScopedArray<T> ]
Ted tells me that EXCEPTION_IN_PAGE_ERROR are paging errors, not wildptrs, so we should unmark as sec.
Group: core-security → gfx-core-security
Group: gfx-core-security
I can't tell if we're doing something wrong, or just hitting a bug in DWrite, or if it's bad data triggering a bug in DWrite.  We just call DWriteFont::CreateFontFace so it seems like it's a bug in DWrite.
Component: Graphics → Graphics: Text
Flags: needinfo?(jfkthame)
Hard to say much without a reproducible test-case, but my guess is that maybe there's a DWrite bug that can be triggered by something weird in a font the user happens to have installed.

I suppose it could be a result of a bug somewhere else (e.g. more-or-less anywhere in our code) having trashed data somewhere, and that's what DWrite then stumbles over, but it's hard to imagine a scenario like that resulting in a consistent crash so deep within dwrite.dll; the presence of a dodgy font resource on the system seems more plausible IMO.
Flags: needinfo?(jfkthame)
Priority: -- → P3
Whiteboard: [gfx-noted]
See Also: → 1529794
QA Whiteboard: qa-not-actionable
Severity: critical → S2
See Also: → 1356399

Given the analysis/theory in comment 4, and the lack of substantial crash volume, this seems more S3-level than S2.

Severity: S2 → S3
You need to log in before you can comment on or make changes to this bug.