1260467 - If your font-config cache has the wrong path to a font file, you may hit "ASSERTION: Failed to make scaled font: 'cairo_scaled_font_status(scaledFont) == CAIRO_STATUS_SUCCESS', file gfx/thebes/gfxFcPlatformFontList.cpp, line 680"

Status: RESOLVED INVALID

(Core :: Graphics: Text, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: backtrace.txt

I get the following assertion-failure when running mochitest layout/style/test/test_initial_computation.html locally. (Maybe other mochitests as well; that just happens to be the one I'm running now, where I noticed it.)
{
###!!! ASSERTION: Failed to make scaled font: 'cairo_scaled_font_status(scaledFont) == CAIRO_STATUS_SUCCESS', file gfx/thebes/gfxFcPlatformFontList.cpp, line 680}
}

Backtrace attached.

Comment 1

[Daniel Holbert [:dholbert]]

Information from gdb when the assertion fails:

(gdb) p scaledFont
$3 = (cairo_scaled_font_t *) 0x7f2298d522f0 <_cairo_scaled_font_nil>
(gdb) p cairo_scaled_font_status(scaledFont)
$4 = 1
(gdb) p sizeMatrix
$5 = {
  xx = 16, 
  yx = 0, 
  xy = 0, 
  yy = 16, 
  x0 = 0, 
  y0 = 0
}
(gdb) p *aFontStyle
$6 = {
  language = {
    mRawPtr = 0x7f227e847430
  }, 
  featureSettings = {
    <nsTArray_Impl<gfxFontFeature, nsTArrayInfallibleAllocator>> = {
    [...SNIP...]
    }, <No data fields>}, 
  featureValueLookup = {
    mRawPtr = 0x0
  }, 
  size = 16, 
  sizeAdjust = -1, 
  baselineOffset = 0, 
  languageOverride = 0, 
  weight = 400, 
  stretch = -4 '\374', 
  systemFont = false, 
  printerFont = false, 
  useGrayscaleAntialiasing = false, 
  style = 0 '\000', 
  allowSyntheticWeight = true, 
  allowSyntheticStyle = true, 
  noFallbackVariantFeatures = true, 
  explicitLanguage = false, 
  variantCaps = 0 '\000', 
  variantSubSuper = 0 '\000'
}

I'm using Ubuntu 16.04 beta. I'm open to the possibility that this is a system-library bug, possibly one that's introduced in this Ubuntu version. (I just upgraded yesterday -- though, I hadn't run this mochitest locally for a while before that, so I can't be sure whether it reproduced on older Ubuntu versions or not.)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a reduced testcase that triggers this assertion for me -- just using "font-stretch: condensed".

(It only triggers it on the first load of this testcase, I think because we cache the [failed] result of the font lookup operation.)

Comment 3

[Jonathan Kew [:jfkthame]]

Do you see a similar problem even with gfx.font_rendering.fontconfig.fontlist.enabled set to false, or is this a possible regression related to the new linux fontlist code?

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew (:jfkthame) [PTO this week] from comment #3)
> Do you see a similar problem even with
> gfx.font_rendering.fontconfig.fontlist.enabled set to false

Yes. Tweaked that pref to false, restarted Firefox, loaded testcase -- same assertion failure.

(I should mention: the testcase also loads as blank for me, in my debug build as well as in up-to-date Nightly.)

Comment 5

[Daniel Holbert [:dholbert]]

(I see these warnings immediately after the assertion-failure, too -- I suspect they're just downstream effects of the failure that's already being reported via the assertion, but I'll mention them here for completeness:

WARNING: shaper failed, expect scrambled or missing text: 'ok', file gfx/thebes/gfxFont.cpp, line 2673
WARNING: failed to shape word - expect garbled text: 'ok', file gfx/thebes/gfxFont.cpp, line 2581

Comment 6

[Jonathan Kew [:jfkthame]]

Just wondering, what font are we trying to use at this point? (You could look at the gfxFcFontEntry's mName and mFamilyName strings in gdb when the assertion fires, and maybe also call FcPatternPrint on its mPattern member.)

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew (:jfkthame) [PTO this week] from comment #6)
> Just wondering, what font are we trying to use at this point? (You could
> look at the gfxFcFontEntry's mName and mFamilyName strings

Both "Ubuntu".


> and maybe also call FcPatternPrint on its mPattern member

That crashed for some reason:
{
(gdb) call FcPatternPrint(mFontPattern)

Thread 1 "Web Content" received signal SIGSEGV, Segmentation fault.
0x00007fdd2543548a in FcPatternPrint ()
}
...but before it crashed, it printed this to my terminal:
> Pattern has 318674000 elts (size 0)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: ubuntu-fonts.tar.gz

My Font Viewer app says I have Ubuntu font version 0.83.

Here's a .tar.gz version of /usr/share/fonts/truetype/ubuntu-font-family/, which I think is where this font lives. (I'm assuming it's Ubuntu-R.ttf, if R stands for Regular.)

Comment 9

[Daniel Holbert [:dholbert]]

...though if I explicitly ask for the Ubuntu font in my testcase, then I don't get the assertion failure (and I can tell that it's a different font from my default one). So it does seem to perhaps be an issue with one particular font, but maybe not the ones I attached in comment 8...

Comment 10

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #7)
> (In reply to Jonathan Kew (:jfkthame) [PTO this week] from comment #6)
> > Just wondering, what font are we trying to use at this point? (You could
> > look at the gfxFcFontEntry's mName and mFamilyName strings
> 
> Both "Ubuntu".
> 
> 
> > and maybe also call FcPatternPrint on its mPattern member
> 
> That crashed for some reason:
> {
> (gdb) call FcPatternPrint(mFontPattern)
> 
> Thread 1 "Web Content" received signal SIGSEGV, Segmentation fault.
> 0x00007fdd2543548a in FcPatternPrint ()
> }
> ...but before it crashed, it printed this to my terminal:
> > Pattern has 318674000 elts (size 0)

Ouch. Well... mFontPattern is an nsCountedRef<FcPattern>, so I guess you may need to explicitly .get() its raw value when calling from gdb. Or something like that... this looks like what was passed wasn't the correct pointer at all.

Comment 11

[Daniel Holbert [:dholbert]]

Also FWIW: I tried to see what font the testcase is actually using, with your Font Information add-on, but it looks like that add-on may not work in up-to-date debug builds.  When I open up Page Info and click Fonts, it's just a blank list and this appears on my terminal:
>JavaScript error: chrome://fontinfo/content/fontinfo.js, line 7: ReferenceError: COPYCOL_NONE is not defined

I tried fixing that locally (replacing that value with -1), but then I get this error
JavaScript error: chrome://fontinfo/content/fontinfo.js, line 73: ReferenceError: gDocument is not defined

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: font pattern dump

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: DejaVuSerifCondensed.ttf

Per my just-attached dump, it looks like this is DejaVuSerifCondensed.ttf, I suppose. Here's that TTF file.

Comment 14

[Jonathan Kew [:jfkthame]]

All sorts of strangeness here... why do you see a font/family name of "Ubuntu" if the pattern is for a DejaVu face? And what's with that ".dpkg-new" on the end of the pathname in the pattern dump?

Re comment 11: yes, I'm aware the add-on is at least somewhat broken, but haven't had time to look into it. You should be able to use the Fonts panel in the element inspector to see what font(s) are being used, though. (You'd need to explicitly enable it with devtools.fontinspector.enabled, though, as it got preffed off by default a little while ago.)

Comment 15

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #11)
> I tried fixing that locally (replacing that value with -1), but then I get
> this error
> JavaScript error: chrome://fontinfo/content/fontinfo.js, line 73:
> ReferenceError: gDocument is not defined

It probably doesn't play well with e10s, if nothing else.

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew (:jfkthame) [PTO this week] from comment #14)
> All sorts of strangeness here... why do you see a font/family name of
> "Ubuntu" if the pattern is for a DejaVu face?

Sorry, that seems to have been a red herring -- I probably caught the wrong call in gdb (maybe I was attached in the wrong process, or we had one call that didn't assert & one that did).

In any case -- now when I attach just after the assertion fails, I see mFamilyName is "DejaVu Serif", 
and mName is "DejaVuSerifCondensed"
 
> And what's with that
> ".dpkg-new" on the end of the pathname in the pattern dump?

I don't know -- that might be part of the problem. If I edit my testcase to use "font: 12px Ubuntu" (which works correctly because as noted above the Ubuntu font is actually fine), then I can see that the "file" line in my FcPatternPrint output ends with Ubuntu-R.ttf, not with dpkg-new.

Comment 17

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #16)
> > And what's with that
> > ".dpkg-new" on the end of the pathname in the pattern dump?
> 
> I don't know -- that might be part of the problem. If I edit my testcase to
> use "font: 12px Ubuntu" (which works correctly because as noted above the
> Ubuntu font is actually fine), then I can see that the "file" line in my
> FcPatternPrint output ends with Ubuntu-R.ttf, not with dpkg-new.

I'm wondering if there could be some kind of weird install-on-demand packaging stuff going on here, and not interoperating well with how we access the fonts.

If you remove the font-stretch setting, so that we (presumably) get the Regular face of DejaVuSans, and dump the pattern that uses, does its pathname have a similar extension, or does it end at the .ttf as we'd normally expect?

A brief look with Google suggests that the .dpkg-new extension is something used by the package manager when updating files -- it'll install a new file with .dpkg-new next to an existing one, then rename the old one to add .dpkg-old and remove the extra extension from the new one, or something like that.

But why did it end up in the fontconfig pattern? And is there in fact a file of that name (I presume not -- hence our failure to create the requested font)?

Maybe running "fc-cache --force" would fix things for you?

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew (:jfkthame) [PTO this week] from comment #17)
> If you remove the font-stretch setting, so that we (presumably) get the
> Regular face of DejaVuSans, and dump the pattern that uses, does its
> pathname have a similar extension, or does it end at the .ttf as we'd
> normally expect?

It ends with .ttf:
 file: "/usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf"(w)

> A brief look with Google suggests that the .dpkg-new extension is something
> used by the package manager when updating files -- it'll install a new file
> with .dpkg-new next to an existing one, then rename the old one to add
> .dpkg-old and remove the extra extension from the new one, or something like
> that.

That makes sense. FWIW, I did an in-place install to go from Ubuntu 15.10 --> Ubuntu 16.10, using Ubuntu's built-in updater.

> But why did it end up in the fontconfig pattern? And is there in fact a file
> of that name

There is no file of that name -- /usr/share/fonts/truetype/dejavu/ only contains .ttf files.

> Maybe running "fc-cache --force" would fix things for you?

That does not fix things for me, sadly.

Comment 19

[Daniel Holbert [:dholbert]]

I can reproduce this (i.e. the attached "testcase 1" renders as a blank page) in an Ubuntu "Guest Session", i.e. a freshly-created user on this system, FWIW. (using Firefox release as my browser in that account).  So whatever's corrupted is outside of my user profile.

But, good news: on a different machine that I also updated to Ubuntu 16.04 yesterday (using the same updater), I can *not* reproduce -- th So that's good -- this isn't universal.  Likely just some broken font state on this one machine.

Comment 20

[Daniel Holbert [:dholbert]]

$ grep -r /usr/share/fonts/truetype/dejavu/DejaVuSerifCondensed.ttf.dpkg-new /var 2>/dev/null
Binary file /var/cache/fontconfig/d589a48862398ed80a3d6066f4f56f4c-le64.cache-4 matches

The "last modified" datestamp on that file is from during the time that I would've been doing the upgrade yesterday.

I'm trying running fc-cache as root now, in case that cleans up that cache file.  (It's owned by root, so running "fc-cache" as my own user wouldn't have had privileges to touch it.)

Comment 21

[Daniel Holbert [:dholbert]]

Yay, running "sudo fc-cache --force" seems to have fixed things for me! Testcase renders non-blank, no assertions, and I can run the mochitest from comment 0 without any assertions now.

Thanks for diagnosing this, jfkthame! (and sorry for eating up your time with what turned out to be not a Firefox bug)

I'm guessing this happened because I opened Firefox while the updater tool was running[1], and fontconfig cached some temporary state that it shouldn't have.

Anyway, I'll resolve this as INVALID, since there doesn't seem to be a real Firefox/Gecko bug here. (The assertion actually helped me find a system issue, so it was kind of a feature! :))

[1] The updater recommends against opening any programs IIRC, but I didn't think any harm would come of it, since I was using a build of Firefox that lived in my home directory & wouldn't be touched by the updater. My bad...

Comment 22

[Jonathan Kew [:jfkthame]]

Great, sounds like we have a plausible explanation for this -- thanks for continuing to prod at it until it finally yielded! :)

It's kind of understandable, I suppose, that launching a program (which may have triggered a fontconfig cache update) while the updater was messing with fonts could catch things in an unfortunate state, but I'd consider it a bug (in the ubuntu updater and/or in fontconfig) that things remained broken thereafter. I believe fontconfig is normally set up to periodically re-scan the font directories, which ought to have sorted things out, but depending how the updater manages file timestamps, it may have mistakenly believed everything was already up-to-date.

(Too bad we didn't record all the relevant file & directory timestamps before fixing things, to see if there was something anomalous-looking there.)