Memory leak with SVG content (on Exynos processor only?)
Reported by
oversoft...@gmail.com,
Feb 16 2017
|
||||||||||
Issue descriptionSteps to reproduce the problem: While using a webview inside our own app, the webview process continually starts using more and more memory while alternating between showing a 1080p video (which uses the exynos video decoder) behind some divs with text and a page which contains no video. Every 15 minutes (give or take) the ActivityManager reports this: system_process I/ActivityManager: Low on memory: system_process I/ActivityManager: MemInfo: 34,992K slab, 15,776K shmem, 27,964K vm alloc, 11,576K page tables 5,936K kernel stack 820K buffers, 165,836K cached, 77,344K mapped, 179,596K free Free RAM: 268,908K Used RAM: 96,244K Lost RAM: 1,681,576K The low memory message happens a couple of times before crashing the webview process. I've enable out-of-process webviews to see if that changes behaviour, but this does not help. I've also tried to destroy each WebView before recreating a new one, instead of using the same one continuously, this does not help either. (Not suprising, since it doesn't seem to spawn a new process on the machine, but keeps on using the same WebView process). Force-closing the app and restarting does help ofcourse, but this is obviously not the intended way to handle this. Under Android 5.1.1, this just crashes the app within 15-minutes with a OOM error. Under Android 7.1 this takes a bit longer, but eventually also crashes the app (with the ActivityManager reports above still happening every 15 minutes). We're using the Odroid XU4 platform which uses the Exynos 5422 chipset. We're able to reproduce it 100% of the time. We've tried Chrome as a Webview, but also the Android system webview and AOSP webview (compiled by myself). We're also using some systems running the Amlogic S905 chip on Android 5.1.1 and on these systems, this crash does not occur, no matter how long we run the pages. (We've tries alternating between a page contain no video and a page containing the 1080p video) Alternating between these pages on stock Chrome also causes memory leaks and eventually a crash. (But since we're using webviews in our app, that's our primary concern) The debug messages that most stand out to me are: 02-16 15:29:12.999 16578-23771/com.my.app.name W/cr_MediaCodecBridge: calling MediaCodec.release() on OMX.Exynos.AVC.Decoder 02-16 15:29:13.007 2945-23788/? W/libexynosv4l2: failed to ioctl: VIDIOC_DQBUF (22 - Invalid argument) 02-16 15:29:13.014 16578-23774/com.my.app.name E/BufferQueueProducer: [SurfaceTexture-55-16578-58] cancelBuffer: BufferQueue has been abandoned (That last message is repeated 8 times with slightly changing timestamps) What is the expected behavior? Being able to play video and change pages indefinitely without crashes. What went wrong? Crashes with out of memory errors on Android 5.1.1. Crashes without out of memory error on Android 7.1. Crashed report ID: No How much crashed? Whole browser Is it a problem with a plugin? No Did this work before? No Chrome version: 56.0.2924.87 Channel: stable OS Version: 7.1 Flash Version: I'm able to test new code pretty quickly as i have a compiler box setup to compile Chromium Webview as well as AOSP Android.
,
Feb 16 2017
,
Feb 17 2017
I'm able to reproduce the issue (but not the crash) on Linux too running Chromium. Same hardware, but then the latest Ubuntu 16.04 image Simply load a page containing a video that's set to autoplay and keep holding F5. On the backend i've logged in with SSH and simple read out the free amount of memory every second, you can see it drop every reload. Eventually it will run out of memory and that triggers a garbage collection (i presume) and then it regains a few hundred megs of memory. It takes a while longer than on Android, but that's presumably because there's more memory available to Chromium. Memory usage starts at about 8% when just started and moves up to over 70% when the garbage collection starts. However, even after 2 hours, the browser does not crash. So although something seems to be gobbling up memory, the linux version of Chromium seems to be able to handle it much better.
,
Feb 17 2017
,
Feb 17 2017
original comment indicates this is a bug that is also seen in chrome. Not specifically a Webview bug. Reproducing only one type of CPU sounds like a driver issue is likely. Further, I don't think we can bisect unless we have the right platform: Odroid XU4 Dale any suggestion? taking it out of webview queue to Chrome queue.
,
Feb 17 2017
Hmm, can you upload a sample page? I'm not able to reproduce on M57 and pressing f5 repeatedly. Memory goes up a bit but GC triggers regularly and usage stabilizes. For a 720p video my usage started around ~46mb, rapid refresh took it to a max of ~115mb, and after stopping it stayed at ~70mb. There are odd cases where your page might be leaking video tags. We try to clean these up as much as possible, but sometimes the spec prevents from having good behavior here.
,
Feb 18 2017
I'll try to upload one this afternoon. I think i've narrowed it down to div overlays that have a non integer opacity. I might be able to trigger it on non-video pages, but it requires some more testing and i don't have access to the XU4 at the moment (it's at the office, i'm at home). It definitely is not triggering on other platforms. The S905 also has a Mali GPU, but it's a different type than the Exynos on the XU4. I've blacklisted hardware video decoding as a test on my compiled WebView (based of off the master earlier this week) and the bug still triggers (but the video obviously does not load). I'll strip the test HTML to the bare minimum to see what triggers the bug. Is there a way to enable more verbose debug output on the WebView? It doesn't really output any useful debug information before crashing (just that the memory usage is high and other process are crashing around it).
,
Feb 20 2017
I've narrowed it down very much. It does not have anything to do with video. I've uploaded a (very stripped down) test page here: http://spiqle.com/test/memoryleak/ It contains no Javascript or CSS animations, so i've ruled those out as well. If either the blue overlay is set to opacity 1 (so, not transparant) or the font is changed to a normal system font, the page does not leak memory. I've tried to changing the blue inline SVG overlay to a solid PNG with the opacity set to 0.5, and that leaks memory too, so it doesn't seem to be linked to using SVG. This page loads fine on my desktop and on the S905 chipset, but it leaks about 20MB of RAM each time it load on the Exynos chipset and crashes the app after it exhausts the memory. (Please note that i'm testing in a WebView and reloading about every 8 seconds) I don't know if it helps, but i attached a 7-zipped performance profile i've taken via chrome://inspect on the attached PC via ADB. It doesn't show an increase in memory though. (I've connected over ADB shell and am running "while [ 1 ] ; do free ; sleep 1 ; done" to keep an eye on memory usage)
,
Feb 20 2017
/addition: If you want, we can close this issue and create a new one, since the topic start is not relevant anymore.
,
Feb 21 2017
Thanks for the report. I'll retriage.
,
Feb 21 2017
>I've tried to changing the blue inline SVG overlay to a solid PNG with the opacity set to 0.5, and that leaks memory too, so it _doesn't_ seem to be linked to using SVG. (emphasis mine)
,
Feb 21 2017
I've tracked it even further, pointing to large WOFF2 fonts. I therefore created a new bug report with number: 694711 Just to reiterate: it's definitely NOT an SVG bug. You can safely remove this bug.
,
Feb 21 2017
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by oversoft...@gmail.com
, Feb 16 20171011 KB
1011 KB View Download