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

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


Attachments

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
Runtime:
Mono 3.2.3 ((no/8d3b4b7)
GTK+ 2.24.20 theme: Raleigh
GTK# (2.12.0.0)
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: 7.0.2.7 (Business Edition)
Hash: 57edee2
Branch: 
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. ***

Note You need to log in before you can comment on or make changes to this bug.