Last Comment Bug 749426 - RenderDocument for entire page of timecube.com OOMs due to CreateSamplingRestrictedDrawable
: RenderDocument for entire page of timecube.com OOMs due to CreateSamplingRest...
Status: VERIFIED FIXED
: mobile
Product: Core
Classification: Components
Component: Layout (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: mozilla15
Assigned To: Vladimir Vukicevic [:vlad] [:vladv]
:
Mentors:
Depends on: 754364
Blocks: 752368
  Show dependency treegraph
 
Reported: 2012-04-26 15:47 PDT by Brad Lassey [:blassey] (use needinfo?)
Modified: 2012-05-24 06:57 PDT (History)
13 users (show)
ryanvm: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
verified
+


Attachments
background tiling testcase (2.09 KB, text/html)
2012-05-11 10:03 PDT, Vladimir Vukicevic [:vlad] [:vladv]
no flags Details
bandaid "fix" (1.10 KB, patch)
2012-05-11 10:47 PDT, Vladimir Vukicevic [:vlad] [:vladv]
jmuizelaar: review+
joe: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Brad Lassey [:blassey] (use needinfo?) 2012-04-26 15:47:30 PDT
when we take our screenshot (here: https://mxr.mozilla.org/mozilla-central/source/widget/android/AndroidBridge.cpp#2176) on timecube.com, Android's OOM killer kills Fennec.
Comment 1 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-05-01 00:33:00 PDT
Very easy to reproduce: just load the page.
Comment 2 Vladimir Vukicevic [:vlad] [:vladv] 2012-05-11 09:38:01 PDT
We've got a couple of huge mallocs happening along the way:

I/GeckoApp(12054): Got message: DOMContentLoaded
I/Gecko-Memory(12054): huge_malloc: 7077888 bytes
I/Gecko-Memory(12054): huge_malloc: 13125208 bytes
...
I/GeckoAppShell(12054): Taking whole-screen screenshot, viewport: ImmutableViewportMetrics v=(0.0,0.0,720.0,1038.0) p=(2091.0,72642.0) z=0.734694
I/Gecko-Memory(12054): huge_malloc: 1105732 bytes
I/Gecko-Memory(12054): huge_malloc: 2097152 bytes
I/Gecko-Memory(12054): huge_malloc: 562785116 bytes

It's that last malloc of half a gig that's understandably killing us off :)
Comment 3 Vladimir Vukicevic [:vlad] [:vladv] 2012-05-11 10:02:53 PDT
Oh, how I've missed EXTEND_PAD-related fun!  This is happening because we need to tile a 198x198 background image into the background, which happens to be very large (~2846 x 98873), but with a noninteger scale along the way.  We end up hitting the CreateSamplingRestrictedDrawable path, which wants to create the full resolution pre-tiled image so that we can get padding/etc. right... and we end up trying to allocate a 2846*98873*2 buffer to hold this temporary image.

Here's the relevant backtrace and some variables:

#0  huge_malloc (size=562785116, zero=false) at memory/jemalloc/jemalloc.c:4978
#1  0x5af9ef52 in imalloc (size=562785116) at memory/jemalloc/jemalloc.c:4194
#2  0x5af9ef6a in __wrap_malloc (size=562785116) at memory/jemalloc/jemalloc.c:6281
#3  0x5bec36b6 in moz_malloc (size=562785116) at memory/mozalloc/mozalloc.cpp:97
#4  0x623439e2 in TryAllocAlignedBytes (aSize=<optimized out>) at gfx/thebes/gfxImageSurface.cpp:122
#5  gfxImageSurface::gfxImageSurface (this=0x63e11400, size=..., format=gfxASurface::ImageFormatRGB16_565, aClear=true) at gfx/thebes/gfxImageSurface.cpp:139
#6  0x623571e8 in gfxAndroidPlatform::CreateOffscreenSurface (this=<optimized out>, size=..., contentType=<optimized out>) at gfx/thebes/gfxAndroidPlatform.cpp:89
#7  0x62354d52 in CreateSamplingRestrictedDrawable (aFormat=<optimized out>, aSubimage=<optimized out>, aSourceRect=<optimized out>, aUserSpaceToImageSpace=<optimized out>, aContext=<optimized out>, aDrawable=<optimized out>) at gfx/thebes/gfxUtils.cpp:322

aFormat = gfxASurface::ImageFormatRGB24
aSourceRect = { x = 0, y = 0, width = 2846.0000240205554, height = 98872.997137164668}
aSubimage = {x = 0, y = 0, width = 2846, height = 98874 }
aUserSpaceToImageSpace = 9 = (const gfxMatrix &) {xx = 5.5585937969151473, yx = 0, xy = 0, yy = 48.277830633381186, x0 = 0, y0 = 0}

needed = { x = 0, y = 0, width = 2846, height = 98873 }
2846 * 98873 * 2 (RGB16) = 562785116 bytes

#8  gfxUtils::DrawPixelSnapped (aContext=0x64369820, aDrawable=0x65b5d290, aUserSpaceToImageSpace=<optimized out>, aSubimage=<optimized out>, aSourceRect=..., aImageRect=..., aFill=..., aFormat=gfxASurface::ImageFormatRGB24, aFilter=gfxPattern::FILTER_GOOD, aImageFlags=1) at gfx/thebes/gfxUtils.cpp:524
#9  0x61cea022 in imgFrame::Draw (this=0x64b04ef0, aContext=0x64369820, aFilter=<optimized out>, aUserSpaceToImageSpace=<optimized out>, aFill=<optimized out>, aPadding=..., aSubimage=..., aImageFlags=1) at image/src/imgFrame.cpp:506

doTile = true!

*this = mImageSurface = {mRawPtr = 0x0}, mOptSurface = {mRawPtr = 0x5e5e6940}, 
  mSize = {<mozilla::gfx::BaseSize<int, nsIntSize>> = {width = 198, height = 198}, <No data fields>}, 
  mOffset = {<mozilla::gfx::BasePoint<int, nsIntPoint>> = {x = 0, y = 0}, <No data fields>}, 
  mDecoded = {<mozilla::gfx::BaseRect<int, nsIntRect, nsIntPoint, nsIntSize, nsIntMargin>> = {x = 0, y = 0, 
      width = 198, height = 198}, 
    static kMaxSizedIntRect = {<mozilla::gfx::BaseRect<int, nsIntRect, nsIntPoint, nsIntSize, nsIntMargin>> = {
        x = 0, y = 0, width = 2147483647, height = 2147483647}, 
      static kMaxSizedIntRect = <same as static member of an already seen type>}}, mPalettedImageData = 0x0, 
  mSinglePixelColor = {r = 0, g = 0, b = 0, a = 0}, mTimeout = 0, mDisposalMethod = 0, 
  mFormat = gfxASurface::ImageFormatRGB24, mPaletteDepth = 0 '\000', mBlendMethod = 1 '\001', 
  mSinglePixel = false, mNeverUseDeviceSurface = false, mFormatChanged = false, mCompositingFailed = false, 
  mNonPremult = false, mLocked = false, mInformedDiscardTracker = true}

#10 0x61ce720e in mozilla::image::RasterImage::Draw (this=0x657fc940, aContext=0x64369820, aFilter=gfxPattern::FILTER_GOOD, aUserSpaceToImageSpace=..., aFill=..., aSubimage=..., aFlags=1) at image/src/RasterImage.cpp:2636

aSubimage = {x = 0, y = 0, width = 2846, height = 98874 }
aUserSpaceToImageSpace = 9 = (const gfxMatrix &) {xx = 5.5585937969151473, yx = 0, xy = 0, yy = 48.277830633381186, x0 = 0, y0 = 0}

#11 0x61d28e78 in DrawImageInternal (aRenderingContext=<optimized out>, aImage=0x657fc940, aGraphicsFilter=gfxPattern::FILTER_GOOD, aDest=<optimized out>, aFill=..., aAnchor=..., aDirty=..., aImageSize=..., aImageFlags=1) at layout/base/nsLayoutUtils.cpp:3611
#12 0x61d2b7d0 in nsLayoutUtils::DrawBackgroundImage (aRenderingContext=0x65bd2240, aImage=0x657fc940, aImageSize=..., aGraphicsFilter=gfxPattern::FILTER_GOOD, aDest=..., aFill=..., aAnchor=..., aDirty=..., aImageFlags=1) at layout/base/nsLayoutUtils.cpp:3778
#13 0x61d14e56 in nsImageRenderer::Draw (this=0x5ec50ec0, aPresContext=<optimized out>, aRenderingContext=..., aDest=..., aFill=..., aAnchor=..., aDirty=...) at layout/base/nsCSSRendering.cpp:4092
Comment 4 Vladimir Vukicevic [:vlad] [:vladv] 2012-05-11 10:03:31 PDT
Created attachment 623198 [details]
background tiling testcase

The attached testcase reproduces this without timecube being involved; it's just a simple 198x198 image as a background of a large page.
Comment 5 Vladimir Vukicevic [:vlad] [:vladv] 2012-05-11 10:47:20 PDT
Created attachment 623213 [details] [diff] [review]
bandaid "fix"

Let's just not call CreateSamplingRestrictedDrawable on mobile.  Fixes the problem for me; waiting on a try server run to see which reftests fail.  Fallout is some rendering artifacts on the edges of some tiled images, and can maybe make some things slower; jrmuizel is working on a patch to make things faster when CSRD is disabled.
Comment 6 Vladimir Vukicevic [:vlad] [:vladv] 2012-05-11 19:59:42 PDT
I don't know how this is possible, but this didn't cause any Android reftests to fail.   There was one orange in the run, but it was a known intermittent failure...
Comment 7 Vladimir Vukicevic [:vlad] [:vladv] 2012-05-14 07:23:11 PDT
Comment on attachment 623213 [details] [diff] [review]
bandaid "fix"

This seems ready to go then.
Comment 8 Jeff Muizelaar [:jrmuizel] 2012-05-14 07:24:18 PDT
Comment on attachment 623213 [details] [diff] [review]
bandaid "fix"

Works for me.
Comment 9 Vladimir Vukicevic [:vlad] [:vladv] 2012-05-16 07:04:53 PDT
Pushed to mozilla-inbound, https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=14a96dac6074
Comment 10 Ryan VanderMeulen [:RyanVM] 2012-05-16 19:48:01 PDT
https://hg.mozilla.org/mozilla-central/rev/14a96dac6074

I guess this is fixed? Please reopen if there's more to be done here.
Comment 11 Adrian Tamas (:AdrianT) 2012-05-18 01:34:40 PDT
Verified fix on:
Build: Nightly 15.0a1 2012-05-17
Device: HTC Desire Z/HTC Deire
OS: Android 2.3.3/Android 2.2

Can load timecube.com and the test case attached in the bug without the device crashing.
Comment 12 Vladimir Vukicevic [:vlad] [:vladv] 2012-05-18 06:01:06 PDT
Comment on attachment 623213 [details] [diff] [review]
bandaid "fix"

[Approval Request Comment]
User impact if declined: excessive memory usage; OOM crashes
Testing completed (on m-c, etc.): on m-c
Comment 13 Vladimir Vukicevic [:vlad] [:vladv] 2012-05-18 13:10:07 PDT
https://hg.mozilla.org/releases/mozilla-aurora/rev/8a6bb72f1882
Comment 14 Catalin Suciu [:csuciu] 2012-05-24 06:57:29 PDT
Verified fixed on: 
Aurora 14.0a2 (2012-05-24)
Beta 14.0b3

Samsung Galaxy SII (Android 2.3.4)

Note You need to log in before you can comment on or make changes to this bug.