1425914 - Crash in Offscreen::getCG (Skia related?)

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is
report bp-ca09ec29-5474-43ab-921a-9e66c0171217.
=============================================================

Only a few crashes, but 2 of the signatures appear to be UAF: http://bit.ly/2kfDm7S

Top 10 frames of crashing thread:

0  @0x7fff773cfd6f 
1  @0x7fff4efd21cd 
2  @0x7fff4ef7a8d0 
3  @0x7fff50e389bc 
4  @0x7fff50e3892c 
5  @0x7fff50e72b83 
6  @0x7fff50e7289f 
7  @0x7fff50f0ed6b 
8  @0x7fff50f0e9aa 
9  @0x7fff50f0dbfa 

=============================================================

Comment 1

[Andrew McCreight [:mccr8]]

Once you get past the unsymbolized frames, the stack looks like this:

Offscreen::getCG(SkScalerContext_Mac const&, SkGlyph const&, unsigned short, unsigned long*, bool)
SkScalerContext_Mac::generateImage(SkGlyph const&)
SkScalerContext::getImage(SkGlyph const&)
SkGlyphCache::findImage(SkGlyph const&)
DrawOneGlyph::operator()(SkGlyph const&, SkPoint, SkPoint)

Comment 2

[Stephanie Ouillon [:arroway] (needinfo me)]

Hi Milan, do you have anyone in your team which could take a look at this bug to figure out what's going on?

Comment 3

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

Timothy, does this look related to the problem you're currently looking at?

Comment 4

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

Also, this does seem to be very rare, but hard to tell with the crash reports gone.

Comment 5

[Timothy Nikkel (:tnikkel)]

(In reply to Milan Sreckovic [:milan] from comment #3)
> Timothy, does this look related to the problem you're currently looking at?

No, it doesn't seem to be related to bug 1414825 as far as I can tell.

Comment 6

[Gian-Carlo Pascutto [:gcp]]

>Also, this does seem to be very rare, but hard to tell with the crash reports gone.

They are trickling in now:

https://crash-stats.mozilla.com/signature/?signature=Offscreen%3A%3AgetCG&date=%3E%3D2018-01-31T16%3A09%3A53.000Z&date=%3C2018-02-07T16%3A09%3A53.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1#reports

Comment 7

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

Let's check if Skia update changes the crash frequency

Comment 8

[Frederik Braun [:freddy] (OOO - back August 10th)]

(In reply to Milan Sreckovic [:milan] from comment #7)
> Let's check if Skia update changes the crash frequency

Is there another Skia update pending or did it happen within the last month?

Comment 9

[Lee Salzman [:lsalzman]]

The Skia update occurred in bug 1444506.

Comment 10

[Lee Salzman [:lsalzman]]

I've eyeballed the Skia code as much as I can, and there is nothing overtly wrong that should result in this crash from there. The worst that I could see is maybe an OOM causing a null pointer access/assertion or something of that sort, but none of the crash reports indicate that. So if there is some bad juju going on, it doesn't look like we're necessarily causing it on our end.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

The address where we're crashing should be system libraries, but they don't match any of the loaded modules. So it's a big of mystery what code is currently executing in these crashes.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

Did a bit of investigation into this for fun:
- My understanding is that dyld_shared_cache is mapped into all processes on startup. This contains the code for a bunch of system libraries.
- We seem to be executing code out of that area for without associating an image for some reason.

Comment 13

[Marcia Knous [:marcia]]

Last crash was in 20190514153425. Should we just resolve this as WFM?

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.