Closed Bug 1229988 Opened 5 years ago Closed 5 years ago
"Assertion failure: a
Target (Don't create a gfx Context without a Draw Target)" with CSS mask
Assertion failure: aTarget (Don't create a gfxContext without a DrawTarget), at gfx/thebes/gfxContext.cpp:78
We're seemingly not checking if CreateSimilarDrawTarget succeeds in a lot of places, and it is allowed to return nullptr. This tries to clean up some of the mess.
Attachment #8698661 - Flags: review?(jmuizelaar)
Do we have any idea if this makes things better in practice?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #3) > Do we have any idea if this makes things better in practice? The alternative is null pointer dereferences happening in random places downstream in release. Or at least, that is the status quo. We'll only get these assertions in debug builds.
Comment on attachment 8698661 [details] [diff] [review] fix callers to check that CreateSimilarDrawTarget succeeds Review of attachment 8698661 [details] [diff] [review]: ----------------------------------------------------------------- When we know that the error return is "OK", and it won't lead to a permanently bad result (e.g., white squares), quietly continuing should be fine. Likely, a gfxDebug() in each place would be useful, it's only noisy in the debug builds. Where it's unknown how the error return would get handled (e.g., we're doing this for the first time), if we used to crash, we should keep crashing using gfxDevCrash; with the goal of converting these to either gfxCriticalNote (we can't explain why this is happening, but now we know how to handle it), or gfxDebug (we can explain why this is happening, see above.)
This is showing up as a topcrash in early results for 46 beta 4. Lee, would you mind taking a look here? If you can't, let's find someone else who can take it on.
The issue in the top crashes is different enough that it is actually best dealt with as a separate problem. It's related to device reset failures with the screen reference draw target. The gfx team is looking into it, and we'll setup a separate bug to deal with.
Assignee: lsalzman → nobody
Status: ASSIGNED → NEW
OK, please nominate the new bug for tracking for 46.
5 years ago
See Also: → 1259513
So, we're already tracking bug 1189715, that's where we'll be dealing with the critical fixes. In the meantime, this problem goes away with the patch from bug 1259513.
Seems to be OK with the combination of patches from bug 1189715 and bug 1259513.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Removing leave-open keyword from resolved bugs, per :sylvestre.
You need to log in before you can comment on or make changes to this bug.