1032072 - Installed Fira Mono / Fira Sans font to system, Firefox crashed in background

Status: RESOLVED DUPLICATE of bug 1070983

(Core :: Graphics: Text, defect)

Description

[Robin Whittleton]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0 (Beta/Release)
Build ID: 20140629030206

Steps to reproduce:

I’m not 100% sure what happened. When I came back to Nightly it had crashed in the background; the previous thing I’d done was use Font Book to install Fira Mono and Fira Sans.


Actual results:

Crash ( https://crash-stats.mozilla.com/report/index/c72fc27e-d947-420d-8f5c-51cef2140630 )


Expected results:

No crash.

Comment 1

[Jonathan Kew [:jfkthame]]

My guess is that for some reason, the rebuilding of the font list (in response to the system "fonts changed" notification) didn't work properly. But I don't know why that would be. That code was last updated in bug 869762, AFAIK, and I'm not aware that it's been having any problems.

Maybe there's some kind of fragile/bad interaction with the async font loader code from bug 962440? If we've discarded the old font list, but haven't yet loaded any faces for the updated list, could we hit this situation?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Note that we're specifically hitting the mFonts.Length() == 0 case that has an NS_RUNTIMEABORT in gfxFontGroup::BuildFontList.

So one question is why the code that tries for a font of last resort failed to find anything.

Comment 3

[Mats Palmgren (inactive)]

I suspect this is the same thing:  bp-79208c32-f388-41d7-a7a3-98ab42141117

Comment 4

[Mats Palmgren (inactive)]

Stupid question: can OSX decide to reallocate the shared font manager and return a different object?
IOW, do we need to redo this line in RegisteredFontsChangedNotificationCallback?
http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxMacPlatformFontList.mm#630

Comment 5

[Steven Michaud [:smichaud] (Retired)]

> can OSX decide to reallocate the shared font manager and return a different object?

The only way to answer this question is to look at the machine code for the +[NSFontManager sharedFontManager] method.  On OS X 10.8.5 the answer is "no".  I'll look at other (major) versions of OS X, but I strongly suspect the answer is "no" for all of them.

Interestingly (at least on OS X 10.8.5), the shared font manager object (stored by the OS) is actually protected against release (in the -[NSFontManager release] method).

Comment 6

[Mats Palmgren (inactive)]

OK, thanks.

Comment 7

[John Daggett (:jtd)]

Although the stack is slightly different, the underlying cause for bug 1070983 is the same, namely that the system fontlist is sometimes not getting built correctly at all. And this has been an ongoing problem for a number of months, the cause is not a recent change.

Comment 8

[John Daggett (:jtd)]

(In reply to Mats Palmgren (:mats) from comment #4)
> Stupid question: can OSX decide to reallocate the shared font manager and
> return a different object?
> IOW, do we need to redo this line in
> RegisteredFontsChangedNotificationCallback?
> http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/
> gfxMacPlatformFontList.mm#630

Note that the system fontlist is constructed using CoreText API's but individual families are flushed out using the shared font manager.