Closed
Bug 1293560
Opened 9 years ago
Closed 7 years ago
Crash in mozilla::gfx::ScaledFontWin::GetFontFileData
Categories
(Core :: Graphics: Text, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: ting, Assigned: eflores)
Details
(Keywords: crash)
Crash Data
Attachments
(2 files, 1 obsolete file)
1.51 KB,
patch
|
jfkthame
:
review+
|
Details | Diff | Splinter Review |
9.28 KB,
patch
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is
report bp-60cdec43-04db-44fa-9b57-d58e82160808.
=============================================================
#12 of 0807 Nightly on Windows, 8 crashes from 2 installations.
Comment 2•9 years ago
|
||
The crash report says
GraphicsCriticalError |[C0][GFX1 24]: Failed to get index for face name |true|. (t=75.2149)
which seems a very strange "face name". Do we need a cast or conversion or something to make it report mLogFont.lfFaceName properly there? It kinda looks like gfxDevCrash may have interpreted it as a bool...
Flags: needinfo?(edwin)
Updated•9 years ago
|
Flags: needinfo?(edwin)
Assignee | ||
Comment 3•9 years ago
|
||
Better fix up that error so we can get some useful data out of this.
Are font names usually okay to truncate to narrow chars? Most of our logging assumes 8-bit characters, sadly.
Assignee: nobody → edwin
Status: NEW → ASSIGNED
Flags: needinfo?(edwin)
Attachment #8780091 -
Flags: review?(jfkthame)
Assignee | ||
Updated•9 years ago
|
Keywords: leave-open
Comment 4•9 years ago
|
||
Most font names are ASCII, so truncating would be harmless, but it's not absolutely guaranteed; in particular, there are some CJK fonts that have names in Chinese or Japanese characters. How about using NS_ConvertUTF16toUTF8 to safely get a utf-8 representation rather than simply truncating the 16-bit code units?
Assignee | ||
Comment 5•9 years ago
|
||
Attachment #8780091 -
Attachment is obsolete: true
Attachment #8780091 -
Flags: review?(jfkthame)
Attachment #8780504 -
Flags: review?(jfkthame)
Comment 6•9 years ago
|
||
Comment on attachment 8780504 [details] [diff] [review]
Convert font name to UTF8 in error message
Review of attachment 8780504 [details] [diff] [review]:
-----------------------------------------------------------------
Yeah, that looks like it should work.
Attachment #8780504 -
Flags: review?(jfkthame) → review+
Pushed by eflores@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d829642ec65d
Fix debug output in ScaledFontWin::GetFontFileData - r=jfkthame
![]() |
||
Comment 8•9 years ago
|
||
I can reproduce the crash when print out on Windows8.1 VM.
And I can still crash on latest m-i cset:ef40e047b7b4bda1eb2d52f277866afaac3d0e2d.
Reproducible : 100%
Steps to reproduce:
1. Open about:home
2. File > Print "Microsoft XPS Document Writer"
3. Enter filename and Click Save
Actual Results:
Tab crashes
bp-615d8647-3566-430f-96fe-908502160817 on Nightly cset:fe895421dfbe1f1f8f1fc6a39bb20774423a6d74
( bp-ca847f2e-2cda-4b45-822d-fd4e72160817 on m-i cset:ef40e047b7b4bda1eb2d52f277866afaac3d0e2d )
Comment 9•9 years ago
|
||
bugherder |
Comment 10•9 years ago
|
||
Crash volume for signature 'mozilla::gfx::ScaledFontWin::GetFontFileData':
- nightly (version 51): 58 crashes from 2016-08-01.
- aurora (version 50): 191 crashes from 2016-08-01.
- beta (version 49): 0 crashes from 2016-08-02.
- release (version 48): 0 crashes from 2016-07-25.
- esr (version 45): 0 crashes from 2016-05-02.
Crash volume on the last weeks (Week N is from 08-22 to 08-28):
W. N-1 W. N-2 W. N-3
- nightly 8 23 24
- aurora 52 66 25
- beta 0 0 0
- release 0 0 0
- esr 0 0 0
Affected platform: Windows
Crash rank on the last 7 days:
Browser Content Plugin
- nightly #103
- aurora #12
- beta
- release
- esr
status-firefox50:
--- → affected
Assignee | ||
Comment 11•9 years ago
|
||
This appears to be coming from fonts in TrueType collections which have more than one full name per font, in most (all?) instances due to having different full names for different languages.
This patch adds a new method to various SFNT parsing classes, GetU16FullNames(), which takes a Vector<u16string> and fills it with *all* of the full names it finds. It also changes GetIndexForU16Name() to check against all of the full names for each font in a TTC.
Attachment #8793228 -
Flags: review?(jfkthame)
Comment 12•9 years ago
|
||
I may well be missing something here, but offhand I don't see why we should need to get and check against *all* the full names from each face. These are simply identifiers that we're using internally, aren't they? (Not names exposed to web content, where an author might have used any of the available languages and so we need to recognize them all.)
So provided we consistently return the same name from GetU16FullName() as we use for lookup in GetIndexForU16Name(), shouldn't it all Just Work? Where do we get lost?
Comment 13•7 years ago
|
||
Closing because no crashes reported for 12 weeks.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Updated•7 years ago
|
Keywords: leave-open
Updated•2 years ago
|
Attachment #8793228 -
Flags: review?(jfkthame)
You need to log in
before you can comment on or make changes to this bug.
Description
•