1489632 - Crash in OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | SkData::PrivateNewWithCopy

Status: RESOLVED FIXED

(Core :: Graphics, defect, P3)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-a9ffc3fc-203e-457a-b9f2-02ad20180906.
=============================================================

Top 10 frames of crashing thread:

0 mozglue.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:34
1 mozglue.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:54
2 mozglue.dll moz_xmalloc memory/mozalloc/mozalloc.cpp:72
3 xul.dll SkData::PrivateNewWithCopy gfx/skia/skia/src/core/SkData.cpp:69
4 xul.dll MakeRasterCopyPriv gfx/skia/skia/src/image/SkImage_Raster.cpp:270
5 xul.dll SkMakeImageFromRasterBitmapPriv gfx/skia/skia/src/image/SkImage_Raster.cpp:309
6 xul.dll SkMakeImageFromRasterBitmap gfx/skia/skia/src/image/SkImage_Raster.cpp:323
7 xul.dll SkImage::MakeFromBitmap gfx/skia/skia/src/image/SkImage.cpp:215
8 xul.dll SkSpecialImage_Raster::onAsImage gfx/skia/skia/src/core/SkSpecialImage.cpp:294
9 xul.dll SkBitmapDevice::drawSpecial gfx/skia/skia/src/core/SkBitmapDevice.cpp:560

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

this crash signature has been present for a while but is spiking up since the end of august for german users with quite high memory allocation sizes, so i suppose it could be related to some sort of external website change triggering this.

marcia, if you have time could you take a look if any url correlations stick out for this signature?

Comment 1

[Marcia Knous [:marcia]]

I don't see any obvious correlations in URLs - here are a few:

*https://www.freenet.de/index.html 
*http://www.spiegel.de/einestages/kriegsende-im-sauerland-a-950018.html 
*https://www.bild.de/sport/2018/sport/jan-ullrich-co-die-gefahr-der-flasche-nach-dem-karriereende-57119944.bild.html

Comment 2

[Andrew Osmond [:aosmond] (he/him)]

The allocations are often quite large (100+MB) and the vast majority of the crashes are on 32-bit systems. I'm not surprised such a large allocation is producing a somewhat notable crash rate on release, but I am surprised skia doesn't gracefully fail. Is there anything to be done here Lee? I'm guessing not, short of an uplift to skia, and even then, we would just stop displaying some content...

Comment 3

[Lee Salzman [:lsalzman]]

Attachment: mark Skia bitmap layer as immutable before popping it

When Skia is popping a layer and trying to composite it, it is temporarily copying the layer because its not immutable. But we're never going to draw to the layer again, so it really is immutable, and should be marked as such. This avoids the copy which is causing this allocation.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/25d9357b7f48
mark Skia bitmap layer as immutable before popping it. r=rhunt

Comment 5

[Lee Salzman [:lsalzman]]

Comment on attachment 9010405 [details] [diff] [review]
mark Skia bitmap layer as immutable before popping it

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1451845
[User impact if declined]: Frequent OOM crashes on any site that needs layering to render.
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: not yet
[Needs manual test from QE? If yes, steps to reproduce]:  no
[List of other uplifts needed for the feature/fix]:
[Is the change risky?]: no
[Why is the change risky/not risky?]: Just avoids an unnecessary allocation that is causing us to OOM.
[String changes made/needed]: none

Comment 6

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/25d9357b7f48

Comment 7

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9010405 [details] [diff] [review]
mark Skia bitmap layer as immutable before popping it

Crash fix, uplift approved for 63 beta 8, thanks.

Comment 8

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/releases/mozilla-beta/rev/f197ee75ff38