Bug 52630 - Android TableView Memory Leak
Summary: Android TableView Memory Leak
Status: CONFIRMED
Alias: None
Product: Forms
Classification: Xamarin
Component: Android ()
Version: 2.3.3
Hardware: PC Windows
: Normal major
Target Milestone: ---
Assignee: Chris King
URL:
Depends on:
Blocks:
 
Reported: 2017-02-20 17:47 UTC by nicolas.dubois
Modified: 2017-06-19 21:29 UTC (History)
3 users (show)

Tags: bug, android, memory leak, tableview, ac
Is this bug a regression?: ---
Last known good build:


Attachments
project (751.47 KB, application/x-zip-compressed)
2017-02-20 17:47 UTC, nicolas.dubois
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 for Bug 52630 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description nicolas.dubois 2017-02-20 17:47:03 UTC
Created attachment 19882 [details]
project

To reproduce :
- hit the buttons for a while => the memory increase


The program is just two buttons and another view. Hitting a button change the view. One of the views contains a TableView with a StackLayout inside. Removing the TableView removes the leak.
Comment 1 Jimmy [MSFT] 2017-02-21 23:19:36 UTC
Thank you for taking the time to file this report! I ran the project attached and alternated pressing the "ListView" and "Buttons" buttons, but I'm not sure if I am seeing the issue you described. Can you let me know the following:

- What tool are you using to monitor memory usage? 
- Does the app eventually crash?
- What Android version have you tested on?
- Any specific repro steps

Thanks!
Comment 2 nicolas.dubois 2017-02-22 10:20:29 UTC
I used motly Android Device Monitor heap tool. On Xamarin Profiler, I see allocations from Java and the visual tree but I don't know much about them.

The phone has Android 5.1.

What I observe (with Android Device Monitor) :
The app starts around 15MB of heap. Then I only press the buttons to switch views (I smash them for 20-30 seconds to have a good increase). The memory goes over 20MB and the number of allocated objets increase.

This is quite difficult to make that simple app crash. I have an app with much more complex views and I get memory increase of 1MB per page. When the memory on the Device Monitor reaches dalvik.vm.heapsize, the app either crash with Java.Lang.OutOfMemoryError or freeze into an infinite (or very long) loop of GC with small allocations.
Comment 3 Jimmy [MSFT] 2017-02-22 22:15:53 UTC
I tested with a Nexus 5X device running Android 7.1 and tried with three different Forms versions. Using DDMS, these are my observations:

## Forms 2.3.3.180 
App launch: 7.6MB heap / 4.6MB allocated / 26,900 objects
~30 secs:   15.6MB heap/ 9.4MB allocated / 108,600 objects


## Forms 2.3.4-pre2
App launch: 7.6MB heap / 4.6MB allocated / 26,900 objects
~30 secs:   13.2MB heap/ 7.9MB allocated / 86,400 objects


## Forms 2.3.5-nightly
App launch: 7.6MB heap / 4.6MB allocated / 26,900 objects
~30 secs:   13.0MB heap/ 7.8MB allocated / 84,900 objects


I am confirming this report as I am seeing the memory increase you mentioned with Forms 2.3.3.180. However it looks like there might be some memory usage improvements in the latest 2.3.4 pre-release that is available, so if possible, you may want to try that newer version to see if it helps in your actual app in the meantime.