Bug 1838 - Memory Usage High
Summary: Memory Usage High
Status: RESOLVED ANSWERED
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 5.0
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2011-11-02 13:08 UTC by Mark Strawmyer
Modified: 2015-03-05 09:07 UTC (History)
6 users (show)

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


Attachments
Source code for test application. (388.52 KB, application/zip)
2011-11-02 13:08 UTC, Mark Strawmyer
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 ANSWERED

Description Mark Strawmyer 2011-11-02 13:08:30 UTC
Created attachment 809 [details]
Source code for test application.

I posted a question on stack overflow at http://stackoverflow.com/questions/7975751/monotouch-memory-use-high/7983132#7983132.  Was asked by responder to post my example here.

I am working to troubleshoot memory issues in my iPhone app.  I created a minimal test app to help isolate.

I'm happy to hop on the phone to describe and discuss if that's helpful at all.  I can be reached at mark.strawmyer@crowehorwath.com
Comment 1 Jeffrey Stedfast 2011-11-02 13:38:37 UTC
Thanks Mark!
Comment 2 Jeffrey Stedfast 2011-11-09 18:23:00 UTC
adding the following code to HandleDoneClicked eliminates most of the leakage (as far as just clicking on a row and then clicking Done goes):

this.detailDescriptionLabel.RemoveFromSuperview();
this.detailDescriptionLabel.Dispose();
this.detailDescriptionLabel = null;

To try and improve this more, I moved all of the Dispose() calls out of HandleDoneClicked() and into a new method called DisposeChildren() which I then called from:

ViewDidUnload ()
Dispose (bool disposing)   // I added this override

Then, in RootViewController.cs I moved detailsViewController to the class level and made sure to dispose it in PushDetails() before allocating a new one.

It would be nice if there was a way to know when the details view was popped in RootViewController so it could Dispose() the detailsViewController immediately there (can't do it in ViewDidAppear() because the detailsViewController gets passed from objc to c# again after that, probably to call ViewDidDisappear() on detailsViewController)

There's also definitely some leakage in the NSBundle.MainBundle.LocalizedString() calls. If I hardcode the strings to "Details" instead of calling NSBundle.MainBundle.LocalizedString ("Details", "Details"), the CFString (immutable) value stops growing after every push/pop pair.

There's still some more leakage I haven't found yet either... another ~27-84 lost per push/pop (each time is different, no idea why) for 16-byte Mallocs.

1 lost 32-bit Malloc per push/pop

2 8-byte Mallocs per push/pop

We're leaking 1 CFDictionary somewhere per push/pop

Leaking 1 CFBasicHash per push/pop

Leaking 1-2 CALayers per push/pop
Comment 3 Jeffrey Stedfast 2011-11-09 18:24:45 UTC
Er, sorry, I should have explained the purpose of moving all the dispose calls into a DisposeChildren() was so that we weren't limited to disposing our child objects only when Done was clicked.
Comment 4 Jeffrey Stedfast 2011-11-09 18:25:23 UTC
also, s/32-bit/32-byte/
Comment 5 Jeffrey Stedfast 2011-11-10 12:37:39 UTC
Cc'ing Kumpera since he is working on improving the GC logistics - this might be a good test case for him.
Comment 6 Andrew Young 2011-11-17 14:49:55 UTC
This sounds similar to what's happening on this bug. http://bugzilla.xamarin.com/show_bug.cgi?id=1840

View controllers don't get collected when they're on a nav controller unless you do something hacky like this..._navController.SetViewControllers(new UIViewController[0], false);
Comment 7 Rolf Bjarne Kvinge [MSFT] 2015-03-05 09:07:00 UTC
I've just tried the test app on device, and I couldn't find any leaks anymore for the "detail view -> Done button" cycle, so whatever there was, we've already fixed it.