Closed
Bug 1407741
Opened 7 years ago
Closed 6 months ago
Crash in ComputeCrc32
Categories
(Core :: Graphics: Text, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
| 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
|
Reporter | |
Comment 1•7 years ago
|
||
[@ 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> ]
|
|
Reporter | |
Comment 2•7 years ago
|
||
Ted tells me that EXCEPTION_IN_PAGE_ERROR are paging errors, not wildptrs, so we should unmark as sec.
Keywords: csectype-wildptr,
sec-high
|
||
Updated•7 years ago
|
Group: core-security → gfx-core-security
|
|
||
Updated•7 years ago
|
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)
|
||
Comment 4•7 years ago
|
||
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)
|
||
Updated•7 years ago
|
Priority: -- → P3
Whiteboard: [gfx-noted]
|
||
Updated•2 years ago
|
Severity: critical → S2
|
||
Comment 5•2 years ago
|
||
Given the analysis/theory in comment 4, and the lack of substantial crash volume, this seems more S3-level than S2.
Blocks: dwrite.dll-crash
Severity: S2 → S3
|
||
Comment 6•6 months ago
|
||
Closing because no crashes reported for 12 weeks.
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•