Closed Bug 1404128 Opened 7 years ago Closed 7 years ago

Graphics crash in lightbeam on OS X with accelerated Skia

Categories

(Core :: Graphics, defect, P3)

Product:
Core
Component:
Graphics
Version:
55 Branch
Platform:
Unspecified
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- fixed
firefox61 --- fixed

People

(Reporter: andy+bugzilla, Unassigned)

References

Details

(Whiteboard: [gfx-noted])

I tried out lightbeam in Firefox 58 Nightly on OS X. Clicked around on the graph that lightbeam produces and got this crash: https://crash-stats.mozilla.com/report/index/03bb35b2-959f-43f1-a200-e3d2f0170928 I tried again a couple more times and could not reproduce.
I bet Milan knows what to do with this. :-)
Component: General → Graphics
Flags: needinfo?(milan)
Product: Firefox → Core
This is in accelerated Skia, but I can't tell if it's just the Skia code or if we're doing something wrong ourselves. It would be OS X only, that's the only place where we do accelerated Skia.
status-firefox57: --- → fix-optional
status-firefox58: --- → fix-optional
Flags: needinfo?(milan) → needinfo?(lsalzman)
OS: Unspecified → Mac OS X
Priority: -- → P3
Summary: Graphics crash in lightbeam → Graphics crash in lightbeam on OS X with accelerated Skia
Whiteboard: [gfx-noted]
Without a testcase I can't make a 100% guarantee, but after doing an investigation of the code, this is extremely likely to just be a GPU resource OOM within Skia, but is otherwise guaranteed to be a problem that is limited to SkiaGL (Mac and Android). The Skia code in this instance is not designed to deal with a texture allocation possibly returning null (beyond a debug assert), and so in release mode, it may crash there. That is the case for Skia m59. Milestones before that don't seem to have this particular allocation code, although they could possibly have other code that has resource OOMs, though not in the same way. In any case, that means this particular bug signature would have been expected to start showing when we updated to m59 with bug 1340627. It looks like the newer Skia milestones restructured this so that it is now more fallible/tolerant of that situation. So I am going to mark this as dependent on a Skia update.
Blocks: 1340627
status-firefox56: --- → wontfix
status-firefox-esr52: --- → unaffected
Depends on: 1368720
Flags: needinfo?(lsalzman)
Version: unspecified → 55 Branch
Given the Skia update has landed in 61 then uplifted to 60, I am going to mark this as resolved for now. If it turns out it is still problematic, we can always reopen.
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox59: ? → wontfix
status-firefox60: --- → fixed
status-firefox61: --- → fixed
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.