Re: Issue 525938 in chromium: android webview chromium out of memory

2,864 views
Skip to first unread message

chro...@googlecode.com

unread,
Aug 28, 2015, 5:11:25 PM8/28/15
to chromi...@chromium.org
Updates:
Labels: Performance-Memory Cr-Mobile-WebView

Comment #1 on issue 525938 by the...@chromium.org: android webview
chromium out of memory
https://code.google.com/p/chromium/issues/detail?id=525938

(No comment was entered for this change.)

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

chro...@googlecode.com

unread,
Nov 18, 2015, 6:38:39 AM11/18/15
to chromi...@chromium.org

Comment #4 on issue 525938 by mofaj...@escenic.com: android webview
I am also getting same crash.

chro...@googlecode.com

unread,
Nov 18, 2015, 11:31:34 AM11/18/15
to chromi...@chromium.org

Comment #5 on issue 525938 by to...@chromium.org: android webview chromium
It's crashing when trying to allocate 96002048 bytes, i.e. 96MB, which
seems pretty big for a single object on a mobile device. How big are the
images/etc you are using?

chro...@googlecode.com

unread,
Nov 18, 2015, 11:46:31 PM11/18/15
to chromi...@chromium.org

Comment #6 on issue 525938 by mofaj...@escenic.com: android webview
I am also getting some oom crash, using webviews inside view pager and
loading high res images inside webview. It first loads, then after swiping
of pages, starts to get slow and laggy, at some point it doesn't load at
all. and giving some chrome error like things and also getting crashed
sometimes,

11-18 15:50:18.146 29747-29822/? A/chromium: [FATAL:memory.cc(18)] Out of
memory. size=40833024
11-18 15:50:18.376 30393-30393/? A/google-breakpad: -----BEGIN BREAKPAD
MICRODUMP-----
11-18 15:50:18.376 30393-30393/? A/google-breakpad: V WebView:46.0.2490.76
11-18 15:50:18.376 30393-30393/? A/google-breakpad: O A arm 04 armv7l
samsung/matisseltexx/matisselte:5.0.2/LRX22G/T535XXU1BOD8:user/release-keys
11-18 15:50:18.376 30393-30393/? A/google-breakpad: S 0 9DDFE350 9DDFE000
00002000

chro...@googlecode.com

unread,
Nov 19, 2015, 7:22:33 AM11/19/15
to chromi...@chromium.org

Comment #7 on issue 525938 by to...@chromium.org: android webview chromium
We can't do anything with logs that don't include the full breakpad
microdump.

chro...@googlecode.com

unread,
Nov 20, 2015, 1:21:58 AM11/20/15
to chromi...@chromium.org

Comment #8 on issue 525938 by mofaj...@escenic.com: android webview
@Torne .. thanks for response, please find the full micro dump in the
link : http://pastebin.com/zZx0SuQf
is it okay ???

Actually this issue is occurring when hardware Accellaration is on, we have
found when acc. is false then it doesn't happen. We can't disable hardware
acc. as we have to play video inside webview.

chro...@googlecode.com

unread,
Nov 20, 2015, 6:57:54 AM11/20/15
to chromi...@chromium.org

Comment #9 on issue 525938 by tobia...@chromium.org: android webview
Thread 0 (crashed)
5 libwebviewchromium.so!base::debug::BreakDebugger [debugger_posix.cc :
217 + 0x3]
6 libwebviewchromium.so!logging::LogMessage::~LogMessage [logging.cc :
645 + 0x3]
7 libwebviewchromium.so!base::::OnNoMemory [memory.cc : 18 + 0x5]
8
libwebviewchromium.so!content::ChildDiscardableSharedMemoryManager::AllocateLockedDiscardableSharedMemory
[child_discardable_shared_memory_manager.cc : 280 + 0x5]
9
libwebviewchromium.so!content::ChildDiscardableSharedMemoryManager::AllocateLockedDiscardableMemory
[child_discardable_shared_memory_manager.cc : 170 + 0xb]
10 libwebviewchromium.so!SkDiscardableMemory::Create
[SkDiscardableMemory_chrome.cc : 32 + 0x7]
11 libwebviewchromium.so!SkDiscardablePixelRef::onNewLockPixels
[SkDiscardablePixelRef.cpp : 61 + 0x5]
12 libwebviewchromium.so!SkPixelRef::lockPixelsInsideMutex
[SkPixelRef.cpp : 120 + 0x9]
13 libwebviewchromium.so!SkPixelRef::lockPixels [SkPixelRef.cpp : 145 +
0x5]
14 libwebviewchromium.so!SkBitmap::lockPixels [SkBitmap.cpp : 223 + 0x5]
15 libwebviewchromium.so!create_unstretched_bitmap_texture [SkBitmap.h :
763 + 0x7]
16 libwebviewchromium.so!GrRefCachedBitmapTexture [SkGr.cpp : 594 + 0x9]
17 libwebviewchromium.so!SkGpuDevice::drawBitmapCommon [SkGpuDevice.cpp :
939 + 0x3]
18 libwebviewchromium.so!SkGpuDevice::drawBitmapRect [SkGpuDevice.cpp :
1447 + 0x3]
19 libwebviewchromium.so!SkGpuDevice::drawImageRect [SkGpuDevice.cpp :
1572 + 0x19]
20 libwebviewchromium.so!SkCanvas::onDrawImageRect [SkCanvas.cpp : 2189 +
0xf]
21 libwebviewchromium.so!SkCanvas::legacy_drawImageRect [SkCanvas.cpp :
1938 + 0xb]
22 libwebviewchromium.so!SkRecords::Draw::draw<SkRecords::DrawImageRect>
[SkRecordDraw.cpp : 101 + 0xf]
23 libwebviewchromium.so!ReplaceDraw::draw [SkRecordDraw.h : 60 + 0x5]
24 libwebviewchromium.so!ReplaceDraw::operator()
[GrRecordReplaceDraw.cpp : 145 + 0x5]
25 libwebviewchromium.so!ReplaceDraw::draw [SkRecord.h : 52 + 0x9]
26 libwebviewchromium.so!GrRecordReplaceDraw [GrRecordReplaceDraw.cpp :
224 + 0x3]
27 libwebviewchromium.so!SkMultiPictureDraw::draw
[SkMultiPictureDraw.cpp : 182 + 0xf]
28 libwebviewchromium.so!cc::GpuRasterizer::RasterizeSource
[gpu_rasterizer.cc : 82 + 0x11]
29 libwebviewchromium.so!cc::::RasterBufferImpl::Playback
[gpu_tile_task_worker_pool.cc : 63 + 0x13]
30 libwebviewchromium.so!cc::::RasterTaskImpl::RunOnWorkerThread
[tile_manager.cc : 133 + 0x1f]
31 libwebviewchromium.so!cc::TaskGraphRunner::RunTaskWithLockAcquired
[task_graph_runner.cc : 418 + 0x3]
32 libwebviewchromium.so!cc::TaskGraphRunner::Run [task_graph_runner.cc :
361 + 0x5]
33 libwebviewchromium.so!base::DelegateSimpleThread::Run
[simple_thread.cc : 87 + 0x7]
34 libwebviewchromium.so!base::SimpleThread::ThreadMain
[simple_thread.cc : 66 + 0x7]
35 libwebviewchromium.so!base::::ThreadFunc [platform_thread_posix.cc : 64
+ 0x7]

chro...@googlecode.com

unread,
Nov 20, 2015, 7:03:56 AM11/20/15
to chromi...@chromium.org

Comment #10 on issue 525938 by tobia...@chromium.org: android webview
In DrawBitmapCommon, srcRect and dstSize are on the stack. Maybe some
wizard could look through the stack contents and pull out those values.

chro...@googlecode.com

unread,
Nov 23, 2015, 9:24:14 PM11/23/15
to chromi...@chromium.org

Comment #11 on issue 525938 by mofaj...@gmail.com: android webview chromium
@tobia , thanks for your response.could you please clarify a bit?? Is there
any thing we can do from our side? .. we are waiting for this. Itz so
crucial for us.

chro...@googlecode.com

unread,
Nov 24, 2015, 8:01:48 AM11/24/15
to chromi...@chromium.org
Updates:
Status: Available
Cc: tobia...@chromium.org
Labels: -Needs-Feedback Cr-Internals-Skia Cr-Blink-Image

Comment #12 on issue 525938 by to...@chromium.org: android webview chromium
Not 100% confident about all of this, but based on dissecting the stack
data and looking at the code with tobiasjs@:

This crash looks like a 3750x2722 pixel image that's being drawn scaled
down, such that the entire image fits on the screen, either because the web
page is zoomed out, or because the site is showing it at smaller than
native size, and the 40MB memory allocation that's failing is the buffer it
intends to decode the image into, so that it can then resample it down to a
smaller size to draw on the screen.

The hardware draw logic checks whether the decoded image is too large for
the GPU and checks various other things to work out whether it should
decode the image all in one go, or in tiles, and because the large image is
still smaller than the maximum texture size and the entire image is needed,
it decides not to tile it, but allocating a shared memory buffer that large
is failing.

It's not that likely that allocating 40MB of memory is actually failing due
to a lack of memory, but what's possibly happening is that the virtual
address space of the webview application has become fragmented too badly
and there might not be a single 40MB chunk of address space left. This
crash seems to mostly happen in apps like reddit readers, pinterest, gmail,
etc - all of which are apps that might be used for a fairly extended period
of time, going through lots of different content with potentailly lots of
of large images embedded. The longer the app gets used for without being
restarted the worse its address space will be fragmented and the lower the
chance that a huge bitmap allocation will succeed.

This is probably much more likely to affect WebView than Chrome itself.
Chrome is multiprocess and so different sites don't always run in the same
renderer, plus renderers get recycled fairly often when navigating between
sites, letting one die and be replaced by a new one, so the odds of a
single renderer's address space being fragmented really badly are pretty
low. Also, on Android, Chrome renderers can be killed by the system to
reclaim memory when they aren't being used to render the foreground tab,
which further keeps their lifetimes relatively short. WebView is
single-process and so the only time the virtual address fragmentation will
get "reset" is when the entire application exits, which will typically only
happen after it's been in the background for a while and the system kills
it to reclaim memory for other apps - if the user's actively interacting
with the app it's not going to be killed and so never gets a chance to
start from a "clean" memory state.

----

So, question for skia/image decoding/etc people:

* Does the above sound plausible? Any ideas how we can test it? (we haven't
reproduced this crash)
* Is this a known issue that just hasn't been addressed because it's rarely
relevant for non-webview use cases?
* Isn't there a way to rescale images while decoding them, such that it's
never necessary to allocate the full size bitmap? Does this only get used
in some cases?
* Should we maybe consider forcing SkGpuDevice::shouldTileBitmap to tile
very large images even if the current checks think tiling isn't necessary?
(maybe just for singleprocess?) Tiled allocations would be smaller
individually and less likely to run into fragmentation issues, even if the
total memory usage is the same.

chro...@googlecode.com

unread,
Nov 24, 2015, 8:02:50 AM11/24/15
to chromi...@chromium.org

Comment #13 on issue 525938 by to...@chromium.org: android webview chromium
Oh, and to the reporters here: sorry, but if this theory is correct there
isn't really anything you can do about this in your application, we'd have
to fix this in WebView. It's just going to crash for users who use your app
for a long period of time and end up on web pages that contain large
images :/

chro...@googlecode.com

unread,
Nov 24, 2015, 8:22:48 AM11/24/15
to chromi...@chromium.org
Updates:
Cc: scro...@chromium.org msar...@chromium.org fma...@chromium.org

Comment #14 on issue 525938 by tomh...@chromium.org: android webview
+ some explicit Image Decode folks

chro...@googlecode.com

unread,
Nov 24, 2015, 9:42:58 PM11/24/15
to chromi...@chromium.org

Comment #15 on issue 525938 by y...@evonit.net: android webview chromium
Hi, I am the one who opened this issue.
My practices shows that the main problem is not because of the huge image,
but Webview does not release all resources even though I release the
webview explicitly.

I made a blog viewer app which is consist of two fragments, one is a list
fragment, second is a webview fragment.
in the first fragment, which is a list page, I can choose a blog article,
and this app show the blog webpage in the second fragment through the
webview.
In some time when I keep navigating the blog many articles, the app is
crashed.
In my exam, when I use huge images as you said, the app die soon, so I
assume that Webview does not clear all the resources.

Torne also can reproduce this crash test as you follow the "Steps to
reproduce the problem"
I also attached the source code link too.
What you need to add in the source code is to crawl webpages in which huge
images exist.

chro...@googlecode.com

unread,
Nov 24, 2015, 11:17:28 PM11/24/15
to chromi...@chromium.org

Comment #17 on issue 525938 by mofaj...@gmail.com: android webview chromium
@chrome developers, thanks a lot for your prompt response. I guess Torne is
right. In our case we are using Web views inside view pager pages, each has
high res images. PROBLEM OCCURS ONLY WHEN HARDWARE ACCELERATION IS ON. We
guess Torne is right with memory fragmentation, because we observed that
both for the H/W acceleration. ON/OFF state shows similar pattern of
memory allocation in Android studio memory monitor. Please let us know if
you havery any query for reproduction.

chro...@googlecode.com

unread,
Nov 25, 2015, 8:30:40 AM11/25/15
to chromi...@chromium.org

Comment #18 on issue 525938 by to...@chromium.org: android webview chromium
#15: have you actually looked at the memory usage over time? Does it
actually keep going up? That would be useful information to know. Your
instructions to reproduce aren't very specific; we've tried loading large
images from a bunch of different places and don't experience this crash. My
theory is that this is a memory fragmentation problem, which would mean
that we *are* releasing the resources, but because of the pattern of
allocation/deallocation of memory the available memory gets cut up into
smaller and smaller pieces over time until there isn't a *single* available
piece large enough to decode a particular large image.

#17: Yes, the image decoding code behaves differently in software vs
hardware mode; in hardware mode it's trying to create a texture for upload
to the GPU instead of just decoding to a plain bitmap, so the allocations
are handled differently (it has to allocate shareable memory which can be
passed to the GPU thread).

If anyone has a specific app *and* specific pages to load which can
reproduce this, we'd like to know so that we can confirm the theory, but
just saying "load different pages with images" isn't a useful repro case;
we've tried that and haven't seen it crash on our devices.

chro...@googlecode.com

unread,
Nov 25, 2015, 10:31:38 PM11/25/15
to chromi...@chromium.org

Comment #19 on issue 525938 by mofaj...@gmail.com: android webview chromium
@Torne,we have observed in two device samsung tab4 with Android 5 and with
nexus 7 with Android 6. It seems like device with larger ram block takes
more time to caught in problem.

The problem path is, swiping through view pager pages, after few times it
can't render the page.. shows black screen and in Android logcat it shows
some allocation problem from chrome process. After that if we try few more
times then some times it falls into oom crash. We have found the crash
mostly in samsung tabs.

We have a Magazine app in the plays tore named "WYPE" . We would try to get
some access for you to check or provide the apk .. preparing for your
reproduction.

Thanks.

chro...@googlecode.com

unread,
Nov 26, 2015, 2:49:56 AM11/26/15
to chromi...@chromium.org

Comment #20 on issue 525938 by tobia...@chromium.org: android webview
@mofajjal: do you have a way to test this without requiring to sign up for
an account / purchase magazines?

chro...@googlecode.com

unread,
Nov 26, 2015, 5:41:56 AM11/26/15
to chromi...@chromium.org

Comment #21 on issue 525938 by mofaj...@escenic.com: android webview
@tobia : sorry for the delay in response, yes we can provide you an apk, we
are going to share with you within short time. i

chro...@googlecode.com

unread,
Nov 26, 2015, 6:35:38 AM11/26/15
to chromi...@chromium.org

Comment #22 on issue 525938 by mofaj...@escenic.com: android webview
@tobia , our test apk is ready , do you have any preferred way of getting
the apk ? through mail or something??

chro...@googlecode.com

unread,
Nov 26, 2015, 8:29:27 AM11/26/15
to chromi...@chromium.org

Comment #23 on issue 525938 by mofajjal...@gmail.com: android webview
https://drive.google.com/file/d/0B3GMCKsBjhxNSWh3UlFhcDRBTGM/view?usp=sharing

@tobia , can you download the apk from above link ??

chro...@googlecode.com

unread,
Nov 26, 2015, 9:27:53 AM11/26/15
to chromi...@chromium.org

Comment #24 on issue 525938 by tobia...@chromium.org: android webview
Yes, I've downloaded the apk. Thanks.

chro...@googlecode.com

unread,
Nov 26, 2015, 11:36:01 PM11/26/15
to chromi...@chromium.org

Comment #25 on issue 525938 by mofaj...@escenic.com: android webview
@tobia, if you have any sort of query, while trying to reproduce the issue
with this apk, please feel free to ask. Thanks to all of you for tremendous
effort.

Please, let the magazine to be fully downloaded first, then try to browse
through pages by swiping, it at first show a preview image in imageview
then loads image in the webview, let the webview finish loading image on
pages, you wouldl obversve that over the time the rendering of webview is
getting slow. Also, please try to browse through clicking on thumbnails, on
top menu there is a button for which thubnails view comes at bottom, please
click on those also to browse pages. Time might vary from device to device
for this issue.

Thanks a lot.

chro...@googlecode.com

unread,
Dec 1, 2015, 12:11:14 AM12/1/15
to chromi...@chromium.org

Comment #27 on issue 525938 by mofaj...@escenic.com: android webview
@Chrome developers, is there any update for this issue? Thanks in advance.

chro...@googlecode.com

unread,
Dec 1, 2015, 12:17:12 AM12/1/15
to chromi...@chromium.org

Comment #28 on issue 525938 by mofaj...@escenic.com: android webview
As, we have published our app in the market, it's being so crucial for our
users to get this fix, as oom is happening randomly, after using a while.
It would be great help from your side.

chro...@googlecode.com

unread,
Dec 6, 2015, 9:58:06 PM12/6/15
to chromi...@chromium.org

Comment #29 on issue 525938 by mofaj...@escenic.com: android webview
@tobia, could you please let us know from your side ??? we are waiting for
your updates. Thanks in advance.

chro...@googlecode.com

unread,
Dec 7, 2015, 6:54:01 AM12/7/15
to chromi...@chromium.org

Comment #30 on issue 525938 by to...@chromium.org: android webview chromium
Please don't post just to ask if there is an update. If there is an update
it will be posted on the bug.

chro...@googlecode.com

unread,
Dec 7, 2015, 7:19:13 AM12/7/15
to chromi...@chromium.org

Comment #31 on issue 525938 by mofaj...@escenic.com: android webview
@torne, thanks for this notification and grant our apology, we appreciate
and are thankful for your tremendous support and hep in our situation with
our published app.
Reply all
Reply to author
Forward
0 new messages