Closed Bug 1295079 Opened 4 years ago Closed 3 years ago

Crash in libfontconfig.so.1.9.0@0x1e15c

Categories

(Core :: Graphics: Text, defect, critical)

50 Branch
Unspecified
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox50 --- unaffected
firefox51 --- fixed

People

(Reporter: njn, Assigned: lsalzman)

Details

(Keywords: crash, regression, Whiteboard: [gfx-noted])

Crash Data

Attachments

(1 file)

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?
Flags: needinfo?(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...
Flags: needinfo?(jfkthame) → needinfo?(lsalzman)
Whiteboard: [gfx-noted]
Keywords: regression
Version: unspecified → 50 Branch
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.
Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
Flags: needinfo?(lsalzman)
Attachment #8782011 - Flags: review?(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.
Attachment #8782011 - Flags: review?(jfkthame) → review+
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.
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.
Keywords: leave-open
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/60d87f012375
check if FcPattern creation fails in gfxFontconfigFontEntry::CreateFontInstance. r=jfkthame
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.
Is it worth uplifting this patch to 50?
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(lsalzman)
Resolution: --- → FIXED
(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.
Flags: needinfo?(lsalzman)
You need to log in before you can comment on or make changes to this bug.