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.
## Steps to reproduce
1. Download and run sample (in next private comment) on a device (Tested on iPhone 7 Plus 10.1 b3)
2. Profile the app with Instruments
3. Tap "Show View" then "Back"
4. Repeat and observe memory usage increase
## Expected result
No memory leak
## Actual result
Tested in the simulator, but was not able to reproduce - only able to reproduce on a device
Included in sample is an Xcode project with the same behaviour, but no leak.
=== Xamarin Studio Enterprise ===
Version 6.1.1 (build 15)
Installation UUID: ad66a985-3d32-4bb5-935b-a2e10c4f0de0
Mono 4.6.1 (mono-4.6.0-branch-c8sr0/ef43c15) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 406010005
=== NuGet ===
=== Xamarin.Profiler ===
=== Xamarin.Android ===
Version: 184.108.40.206 (Visual Studio Enterprise)
Android SDK: /Users/Adam/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
5.0 (API level 21)
5.1 (API level 22)
6.0 (API level 23)
7.0 (API level 24)
SDK Tools Version: 25.2.2
SDK Platform Tools Version: 24.0.3
SDK Build Tools Version: 24.0.1
Java SDK: /usr
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
Android Designer EPL code available here:
=== Xamarin Android Player ===
=== Apple Developer Tools ===
Xcode 8.0 (11246)
=== Xamarin.Mac ===
Version: 220.127.116.11 (Visual Studio Enterprise)
=== Xamarin.iOS ===
Version: 10.0.1.10 (Visual Studio Enterprise)
Build date: 2016-10-03 15:18:44-0400
=== Build Information ===
Release ID: 601010015
Git revision: fa52f02641726146e2589ed86ec4097fbe101888
Build date: 2016-09-22 08:03:02-04
Xamarin addins: 75d65712af93d54dc39ae4c42b21dfa574859fd6
Build lane: monodevelop-lion-cycle8-sr0
=== Operating System ===
Mac OS X 10.12.0
Darwin Adams-Retina-MacBook-Pro.local 16.0.0 Darwin Kernel Version 16.0.0
Mon Aug 29 17:56:20 PDT 2016
An increase of memory is normal and does not imply a leak. In this case you just do not control the lifetime of the instances, nor do you control when the GC is executed. IOW the memory will be freed when the GC eventually runs.
On the simulator we run the GC every two seconds so people can notice issues with unreferenced instances (another kind of bugs). This is why you do not see such condition on the simulator (it exists but it's too short to detect).
Do you mean GC should be called explicitly? If so where is the best place in this case?
I did try in another sample project where I called GC.Collect() on Dispose of the PageRenderer. However, I still be able to crash the app after push/pop the controller a number of times. (It does delay crash for quite a bit of time tho comparing to not calling GC). Please advice. Thanks.
> Do you mean GC should be called explicitly?
No, let the GC do it's job. It's very uncommon to require "hinting" the GC to run in production code (but it can be helpful when debugging as it helps having a more reproducible state).
> However, I still be able to crash the app after push/pop the controller a number of times.
It's likely unrelated to memory growth you were seeing on device (and not on the simulator) but it might be easier to duplicate under lower memory condition.
Please attach a symbolicated crash report and we'll have a better idea about what's going on.
>It's likely unrelated to memory growth you were seeing on device (and not on the simulator)
I'm not too sure what this means? I was able to reproduce on simulator consistently. Please see: http://www.pdftron.com/ID-zJWLuhTffd3c/xamarin/xamarin_memory_leak.mov
From original description:
> Tested in the simulator, but was not able to reproduce - only able to reproduce on a device
Since support filed the issue it's possible that your configuration (and results) might be different. Please copy/paste your version information into the bug report (and with the symbolicated crash report).