Bug 16347 - Xamarin.iOS memory issues
Summary: Xamarin.iOS memory issues
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 7.0.2.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
: 49062 ()
Depends on:
Reported: 2013-11-19 15:03 UTC by Jon Goldberger [MSFT]
Modified: 2017-02-28 16:08 UTC (History)
4 users (show)

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

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 16347 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:

Comment 1 Jon Goldberger [MSFT] 2013-11-19 15:05:13 UTC
We're encountering some memory management issues in one of our apps. The app uses high resolution images where, although they are disposed and nulled, the allocated memory is not freed by the garbage collector. This causes the app's memory usage to increase every time an image is opened, and after opening and closing a few images the memory usage becomes too large and the app is killed by iOS.
Attached is a small project in which an array of 150 megabytes is allocated, but never released by the garbage collector.
We have placed 2 buttons on the screen, the first button tries to free the memory and the second button allocates another 50 megabytes.
Sometimes the 50 megabytes gets collected.

Is there a way around this issue?
Version info:
We don’t get any error messages. The application is killed by iOS.

Version Info:
=== Xamarin Studio ===

Version 4.0.13 (build 38)
Installation UUID: ced8b9b3-bdfa-475c-979b-953d67969932
Mono 3.2.3 ((no/8d3b4b7)
GTK+ 2.24.20 theme: Raleigh
GTK# (
Package version: 302030000

=== Xamarin.Android ===

Not Installed

=== Apple Developer Tools ===

Xcode 5.0 (3332.25)
Build 5A1413

=== Xamarin.Mac ===

Xamarin.Mac: Not Installed

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 57edee2
Build date: 2013-04-10 18:05:51-0400

=== Build Information ===

Release ID: 400130038
Git revision: 07afec667f7be5d0ee511eb7115bbac6377fbae8
Build date: 2013-09-24 08:53:29+0000
Xamarin addins: 61140345a5b109633a94409edcbc7a4c19a425c6

=== Operating System ===

Mac OS X 10.8.5
Darwin Wims-Mac-mini.local 12.5.0 Darwin Kernel Version 12.5.0
Mon Jul 29 16:33:49 PDT 2013
root:xnu-2050.48.11~1/RELEASE_X86_64 x86_64
Comment 2 Jon Goldberger [MSFT] 2013-11-19 15:08:31 UTC
On my suggestion, client tried using the SGen garbage collector setting the "Use the reference counting extension"

Response from client:
Your suggestion improves things a bit, however it still holds on to a large amount of memory. We assume that the memory is retained to be reused when needed, but it often still allocates new memory where the retained memory should suffice. Leading to an increasing memory footprint and eventually a crash.
Comment 3 Jon Goldberger [MSFT] 2013-11-19 15:11:42 UTC
I thought this was similar to bug 8190, and suggested this to the client, but...

Response form client:
This doesn’t appear to be the same as our issue. In the test project even a byte array with a local scope is not always released, even after it is set to null or when it is no longer in scope.
Comment 4 Rolf Bjarne Kvinge [MSFT] 2015-03-05 09:27:06 UTC
I believe this is because of conservative stack scanning in the GC; the GC won't free some of the byte arrays because there is a random value somewhere on a stack that looks like a pointer to inside the array.

Rodrigo can correct me if I'm wrong about this.
Comment 5 Rodrigo Kumpera 2015-03-05 10:48:37 UTC
Yes, the lack of precise stack scanning introduces this issue.
Comment 6 Vincent Dondain [MSFT] 2017-02-28 16:08:27 UTC
*** Bug 49062 has been marked as a duplicate of this bug. ***