1295079 - Crash in libfontconfig.so.1.9.0@0x1e15c

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Nicholas Nethercote [inactive]]

This bug was filed from the Socorro interface and is 
report bp-ebd9e463-758a-489f-804d-89edb2160814.
=============================================================

This crash looks to have started in the July 30 Nightly and has happened 97 times since then. The crash address is always 0x0 but this may be unreliable due to bug 974420(?)

jkew, any ideas?

Comment 1

[Jonathan Kew [:jfkthame]]

Not offhand, except to speculate that we're getting a null FcPattern pointer for some reason. I think Lee has poked around the Linux font code most recently, maybe he has some thoughts here...

Comment 2

[Lee Salzman [:lsalzman]]

Attachment: check if FcPattern creation fails in gfxFontconfigFontEntry::CreateFontInstance

Looked through the Fontconfig source code, and the only reason it seems these particular Fc functions can return null is OOM. So presuming that is the case, then I just added some checks here to ensure the null results don't pollute downstream code.

Comment 3

[Jonathan Kew [:jfkthame]]

Comment on attachment 8782011 [details] [diff] [review]
check if FcPattern creation fails in gfxFontconfigFontEntry::CreateFontInstance

Review of attachment 8782011 [details] [diff] [review]:
-----------------------------------------------------------------

I guess this is fine, though I'm a bit skeptical whether the crash here is _really_ a result of OOM within fontconfig - especially for reports that show an uptime of 1s, which doesn't give the browser very much time to run out of memory. Though no doubt it can be done if one really tries.

Anyhow, I'd suggest leaving this report open for a few days to see whether additional crash reports keep coming in.

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

The majority of the crashes (and there aren't a lot of them, so the conclusions here are not statistically valid), do appear to be "around startup", though there is one with 11 hour uptime.

Comment 5

[Lee Salzman [:lsalzman]]

Well, this patch in theory catches more than OOMs, in that any condition that caused the pattern to be null will now be side-stepped. It is possible that the FcPatternDuplicate call where this crash occurs is happening somewhere else even deeper in libfontconfig, but this did not seem a very likely scenario (yet can't be ruled out).

In any case, will flag this as leave-open in case this patch does not do the job.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/60d87f012375
check if FcPattern creation fails in gfxFontconfigFontEntry::CreateFontInstance. r=jfkthame

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/60d87f012375

Comment 8

[Kartikaya Gupta (email:[e-mail])]

No matching crashes since the 20160812030200 build, which was a good week *before* the patch merged to m-c. So I suspect this should really be WORKSFORME? What's surprising is that the first crash happened while 50 was on Nightly, but I don't see any reports from 50 Aurora.

Comment 9

[Andrew Overholt [:overholt]]

Is it worth uplifting this patch to 50?

Comment 10

[Lee Salzman [:lsalzman]]

(In reply to Andrew Overholt [:overholt] (back Aug 31) from comment #9)
> Is it worth uplifting this patch to 50?

I don't believe so. As noted by Kats, we haven't gotten any other new reports in on this one. And the reports we got in the past appear to have mostly been from one single user.