Closed Bug 1415884 Opened 3 years ago Closed 3 years ago

Crash in SkBitmap::SkBitmap


(Core :: Graphics, defect, P3)

Windows 7



Tracking Status
firefox-esr52 --- unaffected
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- fixed


(Reporter: marcia, Unassigned)


(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is
report bp-971c7c99-3669-4e76-a461-853f50171001.

Seen while looking at nightly crash stats - crashes started using 20170929220356. 54 crashes/22 installs so far. Couldn't find an existing bug that covered this crash. All crashes have crash reason EXCEPTION_ACCESS_VIOLATION_READ.

I thought this was possibly a dupe of another bug, but this seems to have started earlier than the regression range on that bug. ni on Bas since he is working on a fix in that bug and may have some insight.

Top 10 frames of crashing thread:

0 xul.dll SkBitmap::SkBitmap gfx/skia/skia/src/core/SkBitmap.cpp:45
1 xul.dll SkImage_Raster::onReadPixels gfx/skia/skia/src/image/SkImage_Raster.cpp:166
2 xul.dll SkImage::readPixels gfx/skia/skia/src/image/SkImage.cpp:57
3 xul.dll mozilla::gfx::ReadSkImage gfx/2d/SourceSurfaceSkia.cpp:64
4 xul.dll mozilla::gfx::SourceSurfaceSkia::DrawTargetWillChange gfx/2d/SourceSurfaceSkia.cpp:169
5 xul.dll mozilla::gfx::DrawTargetSkia::MarkChanged gfx/2d/DrawTargetSkia.cpp:2190
6 xul.dll mozilla::gfx::DrawTargetSkia::ClearRect gfx/2d/DrawTargetSkia.cpp:1985
7 xul.dll mozilla::dom::CanvasRenderingContext2D::ClearRect dom/canvas/CanvasRenderingContext2D.cpp:3205
8 xul.dll mozilla::dom::CanvasRenderingContext2DBinding::clearRect dom/bindings/CanvasRenderingContext2DBinding.cpp:5307
9 xul.dll mozilla::dom::GenericBindingMethod dom/bindings/BindingUtils.cpp:3053

Flags: needinfo?(bas)
Group: gfx-core-security
Closed: 3 years ago
Flags: needinfo?(bas)
Resolution: --- → DUPLICATE
Duplicate of bug: 1414448
It looks like this was fixed in 58 in bug 1414448. 

There are still crashes showing up in 52.6.0esr, though, and in the corresponding Thunderbird version. 

Al, or Dan, does this need a rating/sec advisory?
Flags: needinfo?(dveditz)
Flags: needinfo?(abillings)
We should take this on ESR52 then. 

Resolving this as a dupe hides it from queries so we probably should just make a dependent link and leave a comment (and set affected and tracking flags) in general.

If we take this in ESR52.7, I'll put it in the comunity rollup advisory for that and go back and add it in the community rollup for 58.
Flags: needinfo?(dveditz)
Flags: needinfo?(abillings)
Bas can you take a look at the remaining crashes? Should we reopen this bug?
Flags: needinfo?(bas)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #4)
> Bas can you take a look at the remaining crashes? Should we reopen this bug?

This bug was a result of OMTP, which doesn't exist in ESR52. Can you point at a crash? It probably has a similar signature but is a very different crash, it may very well not be sec sensitive.
Flags: needinfo?(bas)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #6)
> Here's some reports from ESR & TB 52.6.0:
> 76f910180209
> 1f6140180210
> ae8500180209

All of those are uniquely different bugs, one of them looks like it's us failing at something, but it's a null pointer deref so it's not security sensitive at least.

The other two are a little trickier, but they're both internal to Skia, they sort of look like 'random' corruption. In either case this is not 'one' bug, and it isn't related to the bug we fixed here, so I doubt reopening is useful.
Flags: needinfo?(bas)
Untracking this for ESR52 based on Bas' last reply. We should file a new bug for those signatures if we feel they're worth tracking.
Group: gfx-core-security
You need to log in before you can comment on or make changes to this bug.