Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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 firstname.lastname@example.org
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 = 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:
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
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.
Cc'ing Kumpera since he is working on improving the GC logistics - this might be a good test case for him.
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, false);
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.