Bug 21840 - Frame element/FrameRenderer leaks memory when size changes (Android)
Summary: Frame element/FrameRenderer leaks memory when size changes (Android)
Status: RESOLVED FIXED
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 1.2.2
Hardware: Other Other
: Normal normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-08-05 14:18 UTC by Tomi Blinnikka
Modified: 2015-05-18 15:40 UTC (History)
12 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Sample VS2013 project reproducing the issue (16.61 KB, application/x-zip-compressed)
2014-08-05 14:18 UTC, Tomi Blinnikka
Details
Frame leak test project (3.95 MB, application/zip)
2014-12-18 11:14 UTC, mleclerc
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Tomi Blinnikka 2014-08-05 14:18:58 UTC
Created attachment 7592 [details]
Sample VS2013 project reproducing the issue

Platform:
Android (4.4.2)
Xamarin Forms Version 1.2.2.6243

Overview:
When using the Frame element (Android only) and the size of the frame (i.e. the size of its content) changes, you'll end up with a memory leak and a crash very quickly.

It seems that the FrameRenderer creates a new bitmap every time the size changes, but never disposes of the previous one. This means that you'll quickly allocate several megabytes for each small change; the implementation is sub-optimal just to set the background color and draw a border.

Steps to reproduce:
Change the content of a Frame element, so that the Frame height changes.

I've attached a VS2013 project with the following code that reproduces the issue. I've been able to reproduce the issue on the Android Emulator and hardware (Nexus 5 HAXM/Nexus 5).

---
XAML:
<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
					   xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
					   x:Class="FrameMemoryLeak.MainPage">
  <StackLayout Orientation="Vertical">
    <Frame BackgroundColor="White" HasShadow="True" OutlineColor="Black">
      <Label x:Name="SampleLabel" VerticalOptions="Center" HorizontalOptions="Center" />
    </Frame>
    <Button x:Name="UpdateButton" Text="Update size"/>
  </StackLayout>
</ContentPage>

C#:
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Xamarin.Forms;

namespace FrameMemoryLeak
{
    public partial class MainPage : ContentPage
    {
        private int clickCount;

        public MainPage()
        {
            InitializeComponent();

            Button button = this.UpdateButton;
            button.Clicked += (sender, args) =>
            {
                this.SampleLabel.Text += String.Format("Click count: {0}\n", ++clickCount);
            };
        }
    }
}
---

The Debug log will show something similar to the following for multiple button clicks:

8-05 13:25:29.658 D/dalvikvm( 3163): GC_FOR_ALLOC freed 2K, 36% free 5538K/8632K, paused 2ms, total 2ms
08-05 13:25:29.658 I/dalvikvm-heap( 3163): Grow heap (frag case) to 6.659MB for 1196652-byte allocation
08-05 13:25:29.658 D/dalvikvm( 3163): GC_FOR_ALLOC freed 0K, 23% free 6706K/8632K, paused 2ms, total 2ms
08-05 13:25:29.688 D/dalvikvm( 3163): GC_CONCURRENT freed <1K, 23% free 6707K/8632K, paused 10ms+0ms, total 12ms
08-05 13:25:31.508 D/dalvikvm( 3163): GC_FOR_ALLOC freed 2K, 23% free 6707K/8632K, paused 2ms, total 2ms
08-05 13:25:31.508 I/dalvikvm-heap( 3163): Grow heap (frag case) to 8.002MB for 1408332-byte allocation
08-05 13:25:31.508 D/dalvikvm( 3163): GC_FOR_ALLOC freed 0K, 7% free 8082K/8632K, paused 0ms, total 0ms
08-05 13:25:31.518 D/dalvikvm( 3163): GC_CONCURRENT freed <1K, 7% free 8083K/8632K, paused 0ms+0ms, total 3ms
08-05 13:25:48.998 D/dalvikvm( 3163): GC_FOR_ALLOC freed 2K, 7% free 8083K/8628K, paused 5ms, total 6ms
08-05 13:25:48.998 I/dalvikvm-heap( 3163): Grow heap (frag case) to 9.548MB for 1620012-byte allocation
08-05 13:25:49.018 D/dalvikvm( 3163): GC_FOR_ALLOC freed <1K, 6% free 9665K/10212K, paused 17ms, total 17ms
08-05 13:25:49.028 D/dalvikvm( 3163): GC_CONCURRENT freed <1K, 6% free 9664K/10212K, paused 0ms+0ms, total 2ms
08-05 13:25:49.578 D/dalvikvm( 3163): GC_FOR_ALLOC freed 2K, 6% free 9666K/10212K, paused 3ms, total 4ms
08-05 13:25:49.578 I/dalvikvm-heap( 3163): Grow heap (frag case) to 11.296MB for 1831692-byte allocation
08-05 13:25:49.588 D/dalvikvm( 3163): GC_FOR_ALLOC freed <1K, 5% free 11454K/12004K, paused 8ms, total 8ms
08-05 13:25:50.148 I/dalvikvm-heap( 3163): Grow heap (frag case) to 13.246MB for 2043372-byte allocation
08-05 13:25:50.168 D/dalvikvm( 3163): GC_CONCURRENT freed <1K, 4% free 13450K/14000K, paused 16ms+1ms, total 20ms
08-05 13:25:50.988 D/dalvikvm( 3163): GC_FOR_ALLOC freed 1K, 4% free 13451K/14000K, paused 3ms, total 4ms
08-05 13:25:50.988 I/dalvikvm-heap( 3163): Grow heap (frag case) to 15.396MB for 2255052-byte allocation
08-05 13:25:51.008 D/dalvikvm( 3163): GC_CONCURRENT freed <1K, 4% free 15652K/16204K, paused 11ms+1ms, total 14ms
08-05 13:25:51.818 D/dalvikvm( 3163): GC_FOR_ALLOC freed 1K, 4% free 15654K/16204K, paused 2ms, total 2ms
08-05 13:25:51.818 I/dalvikvm-heap( 3163): Grow heap (frag case) to 17.750MB for 2466732-byte allocation
08-05 13:25:51.838 D/dalvikvm( 3163): GC_CONCURRENT freed <1K, 3% free 18062K/18616K, paused 15ms+0ms, total 18ms
Comment 1 Parmendra Kumar 2014-08-11 12:41:46 UTC
I have checked this issue and I have followed the steps below : 
1. Open the attached demo project.
2. Build/Run it successfully.
When we increase the size of frame, The button is hiding.
Please check the screencast and let me know if I missed anything.

Screencast: http://www.screencast.com/t/ORQkjdDesNGH

Output Log: https://gist.github.com/Parmendrak/bdf815133fbff813d668

Environment info:
Microsoft Visual Studio Professional 2013
Version 12.0.21005.1 REL
Microsoft .NET Framework
Version 4.5.51641

Xamarin   3.3.47.0 (0b2a123923812a88ed3091909478dbe9e0111f00)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android
Comment 2 Tomi Blinnikka 2014-08-11 12:58:27 UTC
I just downloaded and ran the sample project from a clean directory to double-check. I used the Nexus 5 HAXM x86 emulator and ran out of memory before running out of space to expand the label. The output of the log is here:

https://gist.github.com/docBliny/d72971640f45e1772b94

When I originally reported this, I was getting the same result on the physical Nexus 5 phone. Note that I am still running on the trial of Xamarin Business, in case this has any effect on the underlying runtime (and thus garbage collection). 

Microsoft Visual Studio Professional 2013
Version 12.0.30501.00 Update 2
Microsoft .NET Framework
Version 4.5.51641

Xamarin   3.1.228.0 (2349ba7b70529ea26ba842e1ec32d054bd6abb3b)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android

Xamarin.Forms.Core 1.2.2.0
Xamarin.Forms.Xaml 1.2.2.0
Xamarin.Forms.Platform.Android 1.2.2.0

Please let me know what other information I can provide to help reproduce the issue.


//TB
Comment 3 Paul Charlton 2014-09-03 04:20:40 UTC
I came across this bug when searching for answers to a Frame memory leak problem I was experiencing, I've pasted the code to reproduce below, but the key item in my limited testing is that the frame is bigger than the screen area and held within a scrollview.  I've been using the Android Device Monitor and can see the heap size repeatedly increase until it runs out of memory.  I can also confirm that there seems to be some bitmaps on the allocation tracker.

Code, debug, etc pasted below, if you need anything more please let me know.

Regards,
Paul.

Environment:
Microsoft Visual Studio Ultimate 2013
Version 12.0.30723.00 Update 3
Microsoft .NET Framework
Version 4.5.51641


Xamarin   3.3.47.0 (0b2a123923812a88ed3091909478dbe9e0111f00)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android

<package id="Xamarin.Forms" version="1.2.2.6243" targetFramework="MonoAndroid44" />
Xamarin.Forms.Core 1.2.2.0
Xamarin.Forms.Platform.Android 1.2.2.0


---
Allocation tracker:
29	3808880	byte[]	1	android.graphics.Bitmap	nativeCreate	
70	2397680	byte[]	1	android.graphics.Bitmap	nativeCreate	

---
Code:

    public class PlayPage : ContentPage
    {
        public PlayPage()
        {
            this.Content = GenerateContent();
        }

        public View GenerateContent()
        {
            var totst = DateTime.Now;
            var layout = new StackLayout();

            layout.Spacing = 30;
            layout.VerticalOptions = LayoutOptions.FillAndExpand;
            layout.Orientation = StackOrientation.Vertical;
            layout.HorizontalOptions = LayoutOptions.FillAndExpand;
            BackgroundColor = Color.Blue;

            var loadtime = new Label { Text = "(ms): " };

            var totoggle = new StackLayout();
            totoggle.Spacing = 30;
            for (int i = 0; i < 30; i++)
            {
                totoggle.Children.Add(new Label { Text = "Label Toggle #" + i });
            }
            var toggle = new Button { Text = "Toggle Visiblity" };
            toggle.Clicked += (sender, args) =>
            {
                var st = DateTime.Now;
                bool newvis = !totoggle.Children.First().IsVisible;
                foreach (var child in totoggle.Children)
                {
                    child.IsVisible = newvis;
                }
                totoggle.ForceLayout();
                loadtime.Text += (newvis ? "show" : "hide") + ", " + (DateTime.Now - st).TotalMilliseconds + "; ";
            };

            layout.Children.Add(loadtime);
            layout.Children.Add(toggle);

            layout.Children.Add(totoggle);


            loadtime.Text += "initial load, " + (DateTime.Now - totst).TotalMilliseconds + "; ";

            return new ScrollView()
            {
                Content =
                    new Frame
                    {
                        Padding = new Thickness(0, 10, 0, 10),
                        OutlineColor = Color.Red,
                        BackgroundColor = Color.Black,
                        Content = layout
                    }
            };
        }
    }

---
Debug output:
09-03 09:12:47.562 D/dalvikvm(11647): GC_FOR_ALLOC freed 3K, 13% free 11370K/12935K, paused 17ms, total 17ms
09-03 09:12:47.570 I/dalvikvm-heap(11647): Grow heap (frag case) to 14.737MB for 2397680-byte allocation
09-03 09:12:47.601 D/dalvikvm(11647): GC_CONCURRENT freed <1K, 11% free 13710K/15303K, paused 13ms+2ms, total 30ms
09-03 09:12:47.601 D/dalvikvm(11647): WAIT_FOR_CONCURRENT_GC blocked 11ms
09-03 09:12:48.632 D/dalvikvm(11647): GC_FOR_ALLOC freed <1K, 11% free 13711K/15303K, paused 15ms, total 16ms
09-03 09:12:48.640 I/dalvikvm-heap(11647): Grow heap (frag case) to 18.370MB for 3808880-byte allocation
09-03 09:12:48.664 D/dalvikvm(11647): GC_CONCURRENT freed <1K, 9% free 17430K/19079K, paused 2ms+3ms, total 21ms
09-03 09:12:48.664 D/dalvikvm(11647): WAIT_FOR_CONCURRENT_GC blocked 19ms
09-03 09:12:49.625 D/dalvikvm(11647): GC_FOR_ALLOC freed <1K, 9% free 17431K/19079K, paused 14ms, total 16ms
09-03 09:12:49.632 I/dalvikvm-heap(11647): Grow heap (frag case) to 20.657MB for 2397680-byte allocation
09-03 09:12:49.664 D/dalvikvm(11647): GC_CONCURRENT freed <1K, 8% free 19772K/21447K, paused 12ms+2ms, total 32ms
09-03 09:12:49.664 D/dalvikvm(11647): WAIT_FOR_CONCURRENT_GC blocked 20ms
09-03 09:12:50.640 D/dalvikvm(11647): GC_FOR_ALLOC freed <1K, 8% free 19773K/21447K, paused 15ms, total 16ms
09-03 09:12:50.648 I/dalvikvm-heap(11647): Grow heap (frag case) to 24.290MB for 3808880-byte allocation
09-03 09:12:50.679 D/dalvikvm(11647): GC_CONCURRENT freed <1K, 7% free 23492K/25223K, paused 14ms+2ms, total 30ms
09-03 09:12:50.679 D/dalvikvm(11647): WAIT_FOR_CONCURRENT_GC blocked 17ms
Comment 4 Paul Charlton 2014-09-03 04:22:42 UTC
Forgot to mention it's a 7" Galaxy Tab 2(actual device).
Model SM-T210
Running Android version 4.1.2

Paul.
Comment 5 mleclerc 2014-10-27 15:43:31 UTC
I've just ran into this bug, but when playing with an Entry. The frame leaks of 5MB every time the keyboard goes up/down. We had 2 frames in our layout, so we leaked 10MB and crashed after 4-5 up/down.

I've managed to reproduce with a simple app.

App.cs:

using System;
using Xamarin.Forms;

namespace FrameEntryTest
{
    public class App
    {
        public static Page GetMainPage()
        {    
            return new ContentPage
            { 
                Content = new Frame
                {
                    Content = new Entry
                        {
                            Placeholder= "Email"
                        }
                }
            };
        }
    }
}

MainActivity.cs:
add WindowSoftInputMode=SoftInput.AdjustResize to the ActivityAttribute

eg:

[Activity(Label = "FrameEntryTest.Android.Android", MainLauncher = true, ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation, WindowSoftInputMode=SoftInput.AdjustResize)]

Application output of the leaks:
[dalvikvm-heap] Grow heap (frag case) to 6.644MB for 3486732-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.351MB for 1784844-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 11.677MB for 3486732-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 16.706MB for 3486732-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 21.733MB for 3486732-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 26.760MB for 3486732-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 31.788MB for 3486732-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 36.816MB for 3486732-byte allocation


I can reproduce on both 1.2.3.6257 and 1.3.0.6262-pre0.

Nexus 4 from XamAndroidPlayer and Galaxy Nexus real device
Comment 6 Jatin 2014-12-18 04:45:50 UTC
Hi,

I have tried to reproduce this issue at my end using the latest builds.

Below are the steps I followed:
1. Opened the attached Project in VS 2013
2. Debug the project on the simulator with API 19
3. Observed that the application did not crash and logs are appearing in the output.

Output Logs: https://gist.github.com/saurabh360/3ad24c39d85faa79e9b8
XVS logs: https://gist.github.com/saurabh360/7b704b0c428c010a29f5

Build information:
XVS 3.9.164
VS 2013

=== Xamarin Studio ===

Version 5.7 (build 652)
Installation UUID: 522f0c5e-80a3-4414-aec7-1f3b9c1768d1
Runtime:
	Microsoft .NET 4.0.30319.18408
	GTK+ 2.24.22 (MS-Windows theme)
	GTK# 2.12.26

=== Xamarin.Android ===

Version: 4.20.0 (Business Edition)
Android SDK: C:\Users\Admin\AppData\Local\Android\android-sdk
	Supported Android versions:
		2.1    (API level 7)
		2.2    (API level 8)
		2.3    (API level 10)
		3.1    (API level 12)
		4.0    (API level 14)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
Java SDK: C:\Program Files\Java\jdk1.6.0_39
java version "1.6.0_39"
Java(TM) SE Runtime Environment (build 1.6.0_39-b04)
Java HotSpot(TM) Client VM (build 20.14-b01, mixed mode, sharing)

=== Build Information ===

Release ID: 507000652
Git revision: 042e44ba92a6a9c46bd2b69b0b4348df43f381ea
Build date: 2014-12-11 16:21:38-05
Xamarin addins: 06d3aaafde7f726d508e079c9b297cc9aae4af55

=== Operating System ===

Windows 6.1.7601.65536

Note: The application did not crash at my end. Hence, I was not able to reproduce this issue.

Please confirm if you are still facing this issue using the latest builds. And if yes then it will be very helpful if you could please provide us with some more information such as:

1. Emulator (Specific Configuration if any)
2. Build information
3. XVS logs: VS >> Help >> Zip Xamarin Logs

As of now marking this issue as needinfo.
Comment 7 mleclerc 2014-12-18 11:14:26 UTC
Created attachment 9126 [details]
Frame leak test project

Run this app and then select/deselect the entry field a few times. This will make the frame change it's size, thus triggering the bug. For the application to crash, you need to select/deselect a few times for the app to run out of memory.
Comment 8 Andrei.N 2015-04-20 16:42:07 UTC
This happens to me too.
I have a ListView where each item is a Frame with an Image inside.
I have like 10 items, and on simulator, the app crashes very quickly when I start scrolling.
Without the Frame, crash doesn't happen.
Comment 9 Cody Beyer (MSFT) 2015-04-20 17:12:21 UTC
I was able to confirm this using the provided samples.
Comment 10 Brendan Zagaeski (Xamarin Team, assistant) 2015-04-21 19:34:52 UTC
I tried the test cases from both comment 0 and comment 7 today, and it appears that both test cases are fixed as of today's stable version: Xamarin.Forms 1.4.2.6355.


If any users on this bug report can still produce a problem using one of the test cases from comment 0 or comment 7 after updating to Xamarin.Forms 1.4.2.6355, be sure to let us know if any of the following differ from the information I've listed below: (a) the steps to reproduce, (b) the symptoms, (c) the devices used for testing, and (d) the version of Xamarin.Android used to build the app.
O

If any users can reproduce a similar problem using a _different_ test case after updating to Xamarin.Forms 1.4.2.6355, please file a new bug. You are welcome to add a link to that new bug in this bug report once you have filed it.




## Results on 1.4.1.6349: I _can_ reproduce some of the reported symptoms.


- I can reproduce the ever-increasing numbers reported in the "Grow heap (frag case)" messages (as described in comment 0 and comment 5) using the test case attached in comment 0 or comment 7 on Xamarin.Forms 1.4.1.6349.


- Using an Google Android API 19, x86 emulator set to have 192 MB of RAM, I can also produce a _significant_ decrease in app performance (long pauses and skipped frames) after several repetitions of the steps to reproduce. I can reproduce this problem with both test cases.




## Results on 1.4.2.6355: I _cannot_ reproduce the reported symptoms.


- I _no longer_ see an increase in the heap sizes reported by the "Grow heap (frag case)" messages.


- I can _no longer_ produce a decrease in app performance on the Google Android x86 emulator, even after many repetitions of the steps to reproduce.



### Example output from 1.4.2.6355

> [dalvikvm-heap] Grow heap (frag case) to 6.660MB for 3483660-byte allocation
> [dalvikvm-heap] Grow heap (frag case) to 5.039MB for 1781772-byte allocation
> [IInputConnectionWrapper] endBatchEdit on inactive InputConnection
> [dalvikvm-heap] Grow heap (frag case) to 5.274MB for 2027532-byte allocation
> [dalvikvm-heap] Grow heap (frag case) to 6.662MB for 3483660-byte allocation
> [dalvikvm-heap] Grow heap (frag case) to 5.040MB for 1781772-byte allocation
> [IInputConnectionWrapper] endBatchEdit on inactive InputConnection
> [dalvikvm-heap] Grow heap (frag case) to 6.663MB for 3483660-byte allocation
> [dalvikvm-heap] Grow heap (frag case) to 5.040MB for 1781772-byte allocation



## Steps to reproduce for comment 0

1. Run the test case attached to comment 0 on Android device or emulator.

2. Tap the "Update size" button.

3. Repeat step 2 several times.




## Steps to reproduce for comment 7

1. Run the test case attached to comment 7 on Android device or emulator.

2. Tap the text entry item at the bottom of the screen.

3. Tap the "Done" button on the soft keyboard to dismiss the keyboard.

4. Repeat steps 2 and 3 several times.




## Additional version information


### Android devices

Xamarin Android Player 0.3.7 (1), Nexus 4 (KitKat)

LG Optimus L9, Android 4.1.2, API 16

Google Android Emulator, x86, Android API 19


### OS X 10.9.5, MacBook Air

Xamarin.Android 5.1.0.113

Mono 4.0.0 (detached/d136b79)
Comment 11 mleclerc 2015-04-22 11:02:55 UTC
Using Xamarin.Forms 1.4.2.6355, there seems to be a slight increase in memory that happens over time, when trying comment 7

Test from comment 7 with XAP 0.3.7, Nexus 4 KitKat

[dalvikvm-heap] Grow heap (frag case) to 6.650MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.354MB for 1781772-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.354MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.354MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.354MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.354MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.354MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.354MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.355MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.354MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.355MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.355MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.355MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.355MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.355MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.355MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.355MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.356MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.356MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.356MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.356MB for 3483660-byte allocation
[dalvikvm-heap] Grow heap (frag case) to 8.357MB for 3483660-byte allocation


It may only be .001MB at a time, but it seems to be leaking a bit, not sure if significant enough though
Comment 12 Eric Maupin 2015-05-18 15:40:43 UTC
Fixed as per comment 10